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This  voluae  defines  the  capabilities  of  UPS  360  FFS 
Utility  (or ) components.  It  describes  the  fanction  of  each 
utility,  its  inputs,  its  outputs,  and  serves  as  a reference 
for  the  knowledgeable  user  of  these  coaponents. 

This  do  :uaent  supersedes  CSH  U8  15*74,  Voluae  VII. 

CSM  U«  15-74  Voluae  VII,  is  part  of  the  following 
additional  'UPS  360  FFS  documentation: 
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Section  1 


INTRODUCTION 


This  volune  of  the  User  Hanual  contains  an  analytical 
description  of  the  general  utility  support  functions 
provided  by  NIPS  360  FFS.  These  functions  perfora  coanon 
processing  required  by  all  the  coaponents.  The  purpose, 
use,  leek  setup,  and  options  of  each  capability  are 
presented  along  with  clarifying  exanples. 

This  voluae  is  divided  into  the  following  sections: 

a.  TABGEN  - Discusses  the  user  conversion  table 
generator  function 

b.  SUBLDR  - Discusses  the  user  conversion  subroutine 
loader  function 

c.  Data  Conversion  - Discusses  the  data  base 
conversion  function  which  converts  a 1410  FFS  data 
base  to  an  equivalent  MIPS  360  FFS  data  base 

d.  File  Load/Unload  - Provides  the  Job  Control 
Languaqe  to  transfer  files  to  and  fron  the 
Sequential  Access  Method  and  the  Indexed  Sequential 
Access  Method  or  the  Virtual  Storage  Access  Rethod. 

e.  UTQBTQDF  - Discusses  the  creation  of  a NIPS  360  FFS 
data  file  fron  the  answer  file  (QBT/QDF)  produced 
by  the  retrieval  processor  (RASP) 

f.  UTSUBCHK  - Discusses  the  user  subroutine  checkout 
function 

g.  UTDNPLIB  - Discusses  the  capability  of  printing  the 
nanes  of  reports  and/or  logic  statenents  currently 
residing  on  the  data  file 
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h.  UTCLASS  - Discusses  the  capability  of  changing  the 
classification  of  a data  file 

i.  SOURCE  LANGUAGE  STORAGE  - Discusses  the  library 
storage  of  source  programs  to  facilitate 
housekeeping  and  program  maintenance 

j.  UTNDXSPC  - Discusses  the  manner  in  which  indexing 
information  may  be  used  without  running  an  ES  or  FN 
job 

k.  UTNDXTFR  - Discusses  the  capability  which  permits 
the  user  to  transfer  the  entire  data  set,  from  one 
resident  medium  to  the  other 

l.  UTFLDSCN  - Discusses  the  source  statement  field 
reference  scan  function. 

m.  UTNDXKAN  - Discusses  the  capability  to  analyze  the 
words  in  fields  for  which  keyword  indexing  is  to  be 
specified . 

n.  UTNDXKMD  - Discusses  the  maintenance  of  tables  and 
dictionaries  required  for  keyword  indexing. 

o.  UTODE  - Discusses  the  editing  of  user  format 
definition  source  statements  and  their  placement  on 
a user  library. 
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Section  2 


TABGEN 


TABGEN  offers  the  user  the  capability  to  generate  data 
conversion  tables  that  nay  be  used  to  support  input  and 
output  functions  for  NIPS  components. 

This  technique  lends  itself  to  effective  utilization  of 
file  storage  space.  It  also  coapleaents  the  output 
processor  by  expanding  the  coded  internal  storage  values  to 
an  external  readable  fora.  The  HIPS  retrieval  processors 
use  the  reverse  technique  by  permitting  the  user  to  express 
the  longer  readable  fora  as  a search  arguaent.  Table 
conversion  will  change  the  search  value  to  the  internal 
storage  form  for  retrieval  processing. 

Conversion  tables  consist  of  arguaent/function  pairs. 
The  argument  is  called  the  search  value  and  is  the  data  to 
be  converted.  The  function  is  the  corresponding  converted 
value.  irguaents  and  functions  aay  be  fixed  length  or 
variable  length. 

Tables  which  are  used  to  convert  file  data  froa  an 
internal  foraat  to  an  external  format  are  called  Output 
Conversion  Tables.  Tables  which  are  used  to  convert  file 
data  froa  an  external  format  to  an  internal  foraat  are 
called  Input  Conversion  Tables.  Conversion  tables  aay  be 
created  to  perform  both  input  and  output  functions, 
whatever  the  function,  the  table  is  always  entered  with  the 
arguaent  and  the  function  is  returned.  The  tables  designed 
by  the  user  and  linked  to  HIPS  by  the  TABGEM  processor  aay 
be  used  to: 
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a. 

b. 

c. 


Convert  fixed  length  data  to  variable 
Convert  variable  length  data  to  fixed 


length  data 
length  data 


Convert  fixed  length  data  to  fixed  length  data. 


TABGEN  iay  also  be  used  to  delete  a table  or  tables  froa  the 
user's  library. 


2.1  Input 

TABGEN  Mill  accept  as  input  the  following  statements  in 
the  order  indicated: 

a.  Delete  Table  Statement  (optional)  - Statement 
is  used  to  request  deletion  of  a table  or 
tables  froa  the  user's  library. 

b.  Tabla-Iigflljfjcatioa sta£ea§IlE  _l£eguiE£dl  - 

This  control  stateaent  is  used  to  define  the 
name  and  function  of  the  table  and  to  describe 
the  format  of  the  table  value  stateaents. 
TABGEN  provides  the  user  vith  two  aethods  of 
coding  control  stateaents.  These  are  the 
keyword  and  fixed  format  aethods. 

o Keyword  - Hith  the  exception  of  the  table 
naae,  control  paraaeters  nay  be 
identified  in  any  order.  Each  parameter 
is  coded  with  its  associated  operands  and 
is  keyword  identifiable. 

o fixed  * All  paraaeters  are  column 
assigned  for  program  interpretation. 

c.  Hqader  Stateaents  fontlona 1)  - Headers  are 

used  frequently  for  title  information  and  will 
appear  on  each  page  of  the  TABGEN  listing. 

d.  Coaaent  Stateaents  ^optional)  - Comments  are 
often  used  to  describe  the  purpose  of  the 
table,  along  with  any  pertinent  reaarks  the 
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user  wishes  to  sake.  These  statements  will 
appear  only  on  the  first  page  of  the  TABGEN 
listing. 

e.  Table Value Stateaents  (yegqiced]  - Table 

valae  stateaents  supply  the  arguaent/f unction 
pairs  to  the  conversion  table.  The  pairs  aay 
be  arranged  for  input  to  the  table  in  either 
a free  or  fired  foraat. 

o Fired  Format  - The  user  is  required  to 

align  all  arguaent/f unction  pairs  in  the 
saae  column  arrangement,  but  he  has  the 
option  to  choose  this  alignment  as  well 
as  the  argument/function  order.  Both 
arguaents  and  functions  * aay  contain 
eabedded  blanks. 

o Free  Foraat  - The  user  is  not  bound  to 

any  column  alignaent  constraints  for  the 
table  value  statements;  however,  a 
consistent  arguaent/f unction  order  must 
be  maintained  in  the  source  stateaents. 
Either  the  argument  or  the  function  aay 
contain  eabedded  blanks.  If  a value 
contains  embedded  blanks,  it  must  be 
defined  as  the  variable. 


2.1.1  Delete  Table  Statement 

This  stateaent  provides  the  naae(s)  of  tables  to  be 
deleted.  Any  number  of  cards  can  be  submitted,  but  they 
aust  be  first  in  the  TABGEN  deck. 

The  foraat  of  the  DELETE  card  is  as  follows: 

DELETE  - This  keyword  which  indicates  the  stateaent 
type,  nust  be  coded  in  coluan  1 of  the  card. 

a.  the  naae  of  at  least  one  table  to  be  deleted  aust 
appear  on  the  card  before  coluan  72. 
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Eiaaple:  DELETE  DTGIS 

b.  if  aore  than  one  table  aaae  la  to  be  included  on 
the  card,  they  aest  be  eacloaed  in  parentheaia  and 
separated  by  one  blank  or  conaa. 

Ezaaple:  DELETE  (DTGXS,DTGOS) 

c.  A table  naae  or  a list  of  table  nanes  cannot  be 
split  between  cards,  bat  aaltiple  DELETE  cards  can 
be  subaitted. 


2.1.2  Table  Identification  Stateaeat 

This  stateaeat  provides  control  infornation  to  the 
TABGEM  progran.  The  paraaetera  aay  be  keyword  or  fixed 
foraat. 


2. 1.2.1  Keyword  Table  Identification  Stateaeat 

The  keyword  atatenent  ia  the  aathod  used  to  express 
control  paraaetera  in  free  fora,  sith  the  exception  of  the 
conversion  table  naae,  the  osar  aay  specify  the  necessary 
control  paraaetera  ia  any  order.  Only  the  table  naae  is 
required  in  the  table  identification  atatenent.  The 
reaaiaing  paraaetera  are  optional  and  need  only  be  stated  if 
other  than  default  values  are  required.  The  following 
coding  conventions  apply  to  keyword  table  identification 
stateaents: 

a.  Keywords  are  separated  froa  associated  operands 
with  equal  signs. 

b.  Keyword/operand  paraaeters  aay  be  separated  froa 
other  control  paraaeters  by  a conaa  or  blank(s). 

c.  Multiple  operands  assigned  to  a single  keyword  will 
be  enclosed  ia  parentheses. 

d.  More  than  one  card  nay  be  used  to  identify  keyword 

paraneters.  Code  a nonblank  character  in  card 
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j to  indicate  ooatinuatioa 
identification  control  a ta tenants. 


of  table 


Do  not  code  paraaeters  beyond  card  colons  71, 


C'  ‘•r,0Cl/0('*t“'1  1Ut*  *«*••«  «rd 


The  following  statenent  ezenplifies  the  keyword  fornat: 

FONC* (3/1 9, TWO, ▼) 


TIBL3*0CTBST  ABC* (1/1,0IB,F) 
0SB*0  P1GB-2K  USBBI1BB 


statenent; ^l0*in^  «PPlF  to  the  keyword 


“ Th la  keyword,  which  specifies  the  table  naae,  nust 
I^l  a 8 S ! °S  th9.  table  beatification  'clrT 


Bxaaple: 


TlBLE*OCTBST 


“•;»!»  kssj  ‘asr^-rru.-jgaw-jrsa 

t.bl.  Ih.  tollo.1.,  ,.bp«r...t.n  ,S,  iS*  ~^!}f 


hh/11  - This  subparaneter  defines  the  high-  and 

: « as.tf2s"  zjfvsrs&jr 


Bzanple: 


hK6*(1/1) 


b. 


iizinJri«fli!!r!J  X9itS  aay  * aa*d  *•  define  the 
is  ZLiw?  } f ar9«**t.  If  argonent  length 

cJlonir^JJij  .bi,b’  aad  low-order 

fornat**  h 1#  aalaa  cacd*  ac«  free 


* ^ 


Bzanple: 


416*1 
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If  neither  argument  length  nor  colana  alignaent  is 
specified,  the  table  value  cards  will  be  considered 
free  fornat.  The  actual  arguaent  length  will  be 
deterained  froa  the  aaxiaua  length  of  the  argnaents 
in  the  table.  If  arguaent  length  is  greater  than 
30  characters,  the  aaxiaua  length  aust  be  entered 
in  the  PiRH  field  of  the  BXBC  JCL  card.  The  user 
aay  not  specify  bo^fr  coluan  alignaent  and  length  on 
a table  identification  state aunt . 

c.  ONE  ~ The  subparaaeter  ' OHE*  or  *TB0'  aay  be  coded 
to  indicate  the  relative  position  of  the  arguaent 
to  the  function  in  the  table  value  card.  •OHB*  is 
the  default  value  for  the  arguaent;  'THO*  is  the 
default  value  for  the  function.  However,  if  the 
user  overrides  either  position  subparaaeter,  the 
reaaining  subparaaeter  autoanti cally  "flip-flops" 
to  an  opposite  default  value.  If  the  position 
specification  is  not  consistent  with  coluan 
alignaent  reguireaents  for  fixed  foraat  table  value 
cards,  the  coluan  alignaent  specifications  take 
precedence. 

Bxaaples:  1RG= (1/1, OHB) 

Specifies  fixed  fornat  table  value  card, 
with  arguaent  preceding  function. 

AEG* (5,TH0) 

Specifies  free  foraat  table  value  card. 
Arguaent  is  a aaxiaua  of  five  bytes  long 
and  follows  the  function  on  the  table 
value  card. 

i.  F - The  subparaaeter  *F*  indicates  the  arguaent  is 
fixed  in  length  (no  eabedded  blanks).  *v( 
indicates  the  arguaent  is  variable  in  length.  If 
this  subparaaeter  is  oaitted,  the  default  for  the 
arguaent  is  *F«. 

Bxaaple:  ARG= (1/1 ,0IE,F) 
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EfiHC  - This  optional  keyword  with  its  subparaaeters  nay 
appear  anywhere  on  the  table  identification  card  following 
the  TABLE  keyword*  This  defines  the  characteristics  of  the 
table  function.  The  following  snbpnraneters  nay  be  coded: 

a.  hh/11  - This  sabparnneter  defines  the  high*  and 
low-order  col an ns  of  the  function  in  the  table 
value  statenent.  Since  this  defines  specified 
colunn  alignment,  the  table  value  cards  nust  be 
fixed  fornat. 


Bxaaple: 


F0HO3/1 9 


111  - One  to  three  digits  aay  be  used  to  define  the 
aaxiaua  lengths  of  the  function.  If  the  function 
length  is  specified  rather  than  high-  and  low-order 
colunns,  then  the  table  value  card  nust  be  free 
fornat. 


Bxaaple: 


P0IC-17 


If  neither  function  length  nor  colunn  ulignaent  is 
specified,  the  table  value  cards  will  be  considered 
free  fornat.  The  actual  function  length  will  be 
deterained  fron  the  naxinun  length  of  the  functions 
in  the  table.  This  aay  not  exceed  255  bytes.  The 
user  nay  specify  both  colunn  align aent  and 
length  on  a table  identification  stateaent. 

TWO  - The  subparaaeter  *TIO*  or  fOIB'  aay  be  coded 
to  indicate  the  relative  position  of  the  function 
to  the  arguaent  in  the  table  value  card.  »mo»  is 
the  default  value  for  the  function;  •OHE*  is  the 
default  value  for  the  arguaent.  However,  if  the 
user  overrides  either  position  subparaaeter,  the 
reaaining  subparaaeter  autoaatically  "flip-flops" 
to  an  opposite  default  value.  If  the  position 
specification  ia  not  consistent  with  coluan 
ulignaent  reguireaents  for  fixed  foraat  table  value 
cards,  the  coluan  alignaaat  specifications  tnke 
precedence . 


Examples: 


F0IC- (3/19, TUO, V) 
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This  specifies  a fixed  foraat  table  value 
card  with  the  function  in  coluans  3-19. 
The  function  is  variable  length  and 
follows  the  arguaent  on  the  table  value 
card. 


PUEC=  (15,OIE) 

This  specifies  a free  foraat  table  value 
card  with  a aaxiaua  function  length  of  15 
bytes.  The  function  defaults  to  variable 
length  and  precedes  the  arguaent  on  the 
table  value  card. 

d.  v - The  subparaaeter  •?•  indicates  the  function  is 
variable  in  length.  ' P*  is  the  user*s  option  and 
indicates  the  function  is  fixed  length.  If  this 
function  subparaaeter  is  not  coded,  the  default 
value  is  •¥.  • 

use  - This  keyword  paraaeter  aay  appear  anywhere  on  the 
table  identificntion  statenent  card  following  the  TABLE 
keyword.  The  paraaeter  indicates  the  use  of  the  table  for: 

I * Input 
o 3 output 
B = Both 

If  tba  keyword  is  not  coded,  'B*  is  assuaed. 

PACjE  - This  keyword  aay  appear  anywhere  following  the  TABLE 
keyword.  The  subparaaeter  indicates  the  aaxiaua  si2e  of  a 
page  for  the  table.  The  user  has  the  option  to  specify  the 
following  page  sixes: 

IK 

2K 

UK 

If  this  keyword  does  not  appear  on  the  table  identification 
stateaent,  a page  sixe  of  IK  is  assuaed. 
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USBBMAHE  - The  user's  nase  aay  appear  anywhere  on  the  table 
identification  card  after  the  TABLE  keyword.  This  parameter 
is  optional. 


2. 1.2.2  Fixed  Poraat  Table  Identification  Stateaeat 

This  stateaent  is  used  to  express  control  parameters  in 
fixed  foraat.  As  in  the  case  of  the  keyword  table 
identification  stateaent  the  table  naae  and  function,  as 
well  as  the  foraat  of  the  table  value  stateaents,  will  be 
defined  in  this  stateaent.  Specific  coluaa  alignaent  of 
paraaeter  values  is  essential  for  program  interpretation. 
The  following  card  coluaa  alignaent  defines  input  fornats 
for  both  fixed  and  free  format  table  value  stateaents. 


Card 

£olga&s 

1-5 


11-17 


21-27 


31-32 


Fixed  Foraat  Table 


Contains  card  identifier 


TABLE 

Contains  nane  to  be  given 
to  a fixed-to-variable- 
length  conversion  table 

Contains  naae  to  be  given 
to  a variable-to-f ixed- 
length  conversion  table 

High-order  position  of 
fixed  length  field  in 
the  table  value  stateaent 


Free  Foraat  Table 
I ilat-Slat  31 e& t§„ 

Contains  card 
identifier 


TABLE 


Sane 


Sane 


Length  of  fixed 
length  field  in  the 
table  value  stateaent 


34-35  Low -order  position  of 

Fixed  length  field  in 
the  table  value  stateaeat 


Blank 
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t 


% 

k 

I 

* 


Card 

£2  lUll 

Fired  Foraat  Table 

Til  it  mtiwm 

* 

High-order  position  of 
variable  length  field  in 
the  table  value  state- 
aeat 

Free  Foraat  Table 

*1-02 

Length  of  variable 
length  field  in  the 
table  value  stateaent 

**-*5 

* 

Low-order  position  of 
variable  length  field  in 
the  table  value  stateaeat 

Blank 

50 

Contains  code  designating 
use  of  tables 

Sane 

1 ■ Input 

0 * Output 

B - Both 

51  . 

Blank 

Contains  *F*  if 
the  fired  field  is  the 
first  field  in  the 
table  value  stateaeat; 
contains  'S'  if  the 
fired  field  is  the 
second  field  in  the 
table  value  stateaeat 

55 

Contains  the  user's 
naae 

Sane 

73-80 

Card  deck  segueace 
nun bar  if  desired 

Sane 

2-  1.3 

Header  Stateaeat 

Header  stateaeats  are  optional  and  aay  be  used  with 
keyword  or  fired  foraat  control  stateaeats.  For  each  table 
generated  by  the  T1B6II  processor*  a listing  will  be 
provided  to  the  user.  Op  to  four  user-specified  header 
lines  aay  be  printed  on  each  page  of  the  generated  table 
listiag.  A header  stateaeat  is  identified  by  one*  two* 
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three,  or  four  asterisks  left- Justified  in  coluans  1-4 
representing  the  statsasnts  (lines)  one,  t»o,  three,  or 
four.  Data  printed  on  each  page  of  the  output  listing  is 
taken  fron  coluans  10-80  of  a statesent.  for  example: 

Card  Colunn 
1 10 

* THIS  IS  AN  OUTPUT  HBADBR 

**  THAT  BILL  APPBAB  IN  THIS  ORDER 

*♦*  ON  EACH  PAGE  OP  OUTPUT  OP 

****  A TABGBN  LISTING. 


2.1.4  Consent  Statenent 

A coanent  stateaent  is  identified  by  an  asterisk  in 
colons  6.  Any  nuaber  of  coanent  stateaents  any  be  applied 
by  the  user,  but  they  aust  folios  the  header  statenent  and 
precede  the  table  value  at ate nests.  The  contents  of  a 
coanent  stateaent  will  be  printed  exactly  as  it  appears  on 
the  punched  card.  For  exanple: 

Card  Colunn 
6 10 


THIS  IS  A COBRBNT  STATBB BBT 
THAT  BILL  APPEAR  OB  THE  PIBST 
PAGE  OBIT  OF  A TABGBN  LISTING. 

THERE  HAY  BE  ANT  NUHBBR  OP 
CONSENT  STATBHBNTS  PRIOR  TO  THB 
OUTPUT  OF  THE  TABLE  TALUB  STATBHBNTS. 


2.  1.5 


Table  Value  Stateaents 


Arguaent/f unction  pairs  are  supplied  to  TABGBN  by  table 
value  stateaents.  If  the  keyword  table  identification 
stateaent  is  used,  the  user  nay  create  a table  in  which  the 
argunent/functioa  pair  nay  have  a conbined  length  of  256 
characters.  If  this  aethod  is  used  and  the 
arguaent/f unction  pair  exceeds  71  characters,  the  table 
value  stateaents  should  be  continued  to  the  next  card.  A 


Ut  ility  Support  (OT) 


aaxiaua  of  four  contiaaatioa  cards  is  poraitted.  k nou- 
blaak  character  ia  coluan  72  aill  indicate  continuation. 
The  scan  uill  proceed  through  colunn  71  and  continue  with 
coluan  1 on  the  next  card. 

If  the  fixed  table  identification  stateaent  is  eaployed, 
the  arguaent /function  pair  aust  be  contained  within  the 
coluan  boundaries  of  one  punched  card. 

In  either  case,  table  value  stateaent s aay  appear  in  one 
of  two  fornats;  i.e.,  fixed  or  free.  Exaaples  of  each 
follow. 

a.  Fixed  Foraat  - The  user  is  reguired  to  align  all 

arguaent/f unction  pairs  in  a prescribed  coluan 
arrangeaent.  The  coluan  aligaaent  and 

arguaent/f unction  order  are  optional;  however,  all 
table  value  inputs  aust  have  the  saae  foraat.  For 
exaaple,  the  following  table  value  sta tenants  would 
supply  arguaent /function  pairs  in  fixed  foraat  to 
a "Service  Table": 

Card  Coluan 

13  19 

B U.S.  Coast  Guard 
B u.s.  bray 
J U.S.  Air  Force 
1 U.S.  Ravy 
H u.s.  Marine  Corps 

Using  the  fixed  foraat  table  value  stateaents,  the 
high-  and  low-order  positions  of  the 
arguaent/f unction  pairs  aust  be  specified  in  the 
table  identification  stateaent.  Fixed  foraat  table 
value  stateaents  can  contain  blanks  in  both  fixed 
and  variable  length  fields. 

b.  Free  Foraat  - The  user  is  not  United  by  coluan 
boundary  restrictions  using  the  free  foraat  aethod 
for  input  of  table  value  stateaents.  Data  nay 
start  in  any  card  coluan  and  end  ia  any  card  coluan 
between  coluans  1 and  71,  inclusive,  for  keyword 
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table  identification  control  cards,  and  between 
coluans  1 and  80,  inclusive,  for  fixed  table 
identification  control  cards.  The  order  of 
argunent/f unction  pairs  nnst  be  indicated  and 
renain  consistent  for  all  inputs  to  a single  table. 
For  ezaeple,  the  following  table  walne  statements 
would  supply  arguaent/f unction  pairs  to  a "Service 
Table": 

E u.s.  Coast  Guard 

a U.S.  Aray 
J U.S.  Air  Force 

N U.S.  Navy 
H U.S.  Narine  Corps 

The  order  of  arguaent/f unction  pairs  in  the  exaaple  shown 
reaains  consistent  in  each  table  value  statenent.  However, 
colunn  selection  of  data  value  placenent  is  free  fornat.  In 
this  foraat  the  fixed  length  field  cannot  contain  eabedded 
blanks,  but  the  variable  length  field  can. 


2.2  Job  Setup 

a.  The  following  job  setup  is  used  to  execute  the 
XTABGBN  cataloged  procedures  and  aust  be  organized 
in  the  order  shown: 

//Jobnaae  JOB  (Standard  paraneters) 

//Stepnaae  EXBC  XTABGBN, LIB = your lib 

//TAB.SYSIN  DD  * 

TABLE  IDENTIFICATION  STATBNENT  (Required) 

HEADER  STATBNENT  (Optional) 

COHHENT  STATBHBNT  (Optional) 

TABLB  TALUB  STATEN ENTS  (Required) 

/* 

b.  Nore  than  one  table  nay  be  generated  in  a single 

job  step.  If  tables  are  batched  and  a table 
argunent  length  exceeds  30  bytes,  TABGBN  nnst  be 
inforaed  by  stating  the  aaxiaan  argunent  length  in 
the  PARE  field  of  the  BXBC  card,  for  exaaple, 

PlRH*nnn  (nnn  is  any  nuaber  between  1 and  255). 
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c.  The  generated  table  will  become  an  executable  load 
nodule  uhich  will  reside  as  a aenber  of  a library 
that  will  be  identified  by  the  LIB*  paraneter  in 
the  BXBC  card.  The  user  nay  create  his  own  new 
library  by  owerriding  the  following  syabolic 
para  enters: 

LIBDISP*  ( IBV,  K EBP) 
f LIB=  (woluae) 

II BSP=  (space) 

DLIB*  (unit) 


2.3  Linitations 

a.  The  nazinun  table  size  is  approxirately  528,000 
bytes  The  nazinun  nunber  of  pages  which  any  table 
nay  contain  is  132. 

b.  The  nazinun  a rgunent/f unction  size  is: 

o.  25b  bytes  when  using  keyword  table  identification 
stateaents 

o.  80  bytes  when  using  fixed  table  identification 
stateaents. 


2.4  Exaaples 

Bzanples  of  test  runs  using  keyword  table  identification 
stateaents. 

a.  The  following  ThBGEI  source  deck  setup  was  used  to 
generate  a fized-to- variable  length  table  using 
free  fornat  table  value  stateaents.  The  table  naae 
is  CTBTS,  and  the  table  converts  a two-character 
internal  storage  code  to  an  output  value  with  a 
nazinun  length  of  15  characters.  The  user  nane  is 
T1BGBITEST  and  the  table  page  size  is  2,000 
characters. 
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//Jobnane  JOB  (standard  paraaeters) 

//STEFA  BXEC  ITABGEN,LIB»yourlib 

//TAB*  SYSIN  DD  * 

TABLE*CTRTS  AHG=2  F0NC*=15  0SE*0  PAGB=2K  TABGENTEST 
♦ TABLE  CTBYS  USING  PBEB  POBHAT  TABLE 
**  ID  ENTIPICATION  CABD  AID  TABLB  VALUE 
***  CARDS. 

AA  AFRICA 

AC  ATLANTIC  OCEAN 


64 


/* 


CARIBBEAN 

65  PACIFIC  ISLANDS 


The  output  listings  for  this  source  deck  will 
appear  as  follows: 


DATE  71001  TABLE-CTRYS  ORIGINATOR  TABGENTEST  PAGE-001 

TABLE  CTBYS  USING  PBSE  FORK  AT  TABLE 
IDENTIFICATION  CARD  AND  TABLE  VALUE 
CARDS. 

ARGOHBNT  FUNCTION 


AA 

AC 


AFRICA 

ATLANTIC  OCBAN 


64 

65 


CARIBBEAN 
PACIFIC  ISLANDS 


b.  The  following  TABGEN  source  deck  setup  was  used  to 
generate  a variable-to-fixed  length  conversion 
table  using  fixed  foraat  table  value  statements. 
The  table  naae  is  UNLVSI,  and  the  table  is  used  to 
convert  an  external  value  with  a naxiaua  length  of 
15  characters  to  an  input  storage  code  with  a 
naxiaua  length  of  three  characters.  The  user  nane 
is  TABGENTEST  and  the  table  page  size  is  1,000 
bytes: 


//Jobnaae 

//STEPA 


JOB  (standard  paraaeters) 
BXEC  XTABGEN,LIBcyour lib 
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//TAB. SYS IN  DD  * 

TABLEAU ML VSI  ARG=10/24  FUBOI/3  USE=I  TABGBHTBST 
* TABLE  OBLYS  USING  KEYWORD  TABLE  IDENTIFICATION 

**  STATEHENTS  AND  FI I ED  FOBNAT  TABLE  VALUE 
CARDS. 

A RUBBERED  ARHY 

ACD  ACADEMY 


U UNIT 

OSS  US  SHIP 

UG  WING 

/* 

The  output  listing  for  this  source  deck  will 
appear  as  follows: 

DATE  71007  TABLB-ONLVSI  ORIGINATOB-TABGENTEST  PAGE-001 

TABLE  UNLVS  USING  KEYWORD  TABLE  IDENTIFICATION 
STATEMENT  AID  FIXED  FORMAT  TABLE  VALUE 
CARDS. 

ARGUMENT  FUNCTION 


NUMBERED  ARMY  A 
ACADEMY  ACD 


UNIT  0 

OS  SHIP  USS 

WING  WG 
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Section  3 


SUBLDR 


SUBLDB  is  used  to  transfer  a conversion  subroutine  in 
lo  id  module  forn  fro»  a work  library  to  the  KIPS  library. 
This  procedure  establishes  the  proper  linkage  for  the 
interface  between  the  KIPS  360  FFS  and  the  user  subroutine. 
The  subroutine  should  have  been  tested  previously  by  the 
user.  The  conventions  required  in  writing  the  subroutine 
have  been  outlined  in  Volume  I,  Introduction  to  File 
Concepts. 


3.1  Input 

Input  for  the  cataloged  procedure  ISUBLDR  comes  from  two 
sources:  a user-supplied  statement  in  the  Job  deck  defining 

the  attributes  of  his  subroutine,  and  the  subroutine  in  load 
nodule  form.  The  location  of  this  load  aodule  is  identified 
by  a symbolic  parameter  supplied  by  the  user. 

The  free  format  control  statement  defines  the 

subroutine,  and  is  punched  on  a card.  The  parameters  must 
be  in  their  stated  order  but  nay  be  separated  by  blanks  or 
commas  and  may  start  in  any  card  column.  The  nine 

parameters  used  in  the  control  statement  are  as  follows: 

a.  Statement  Identifier  - SUBRT 

b.  Conversion  Subroutine  (fame  - Hane  to  be  used  in 

NIPS  360  FFS  statements  when  invoking  the 

subroutine.  This  name  must  conform  to 
specifications  outlined  in  Volume  I,  Introduction 
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to  File  Concepts,  and  aast  bo  anigue  in  the  VIPS 
library  vhere  tbo  sabroatino  is  stored. 

Baxiaaa  Arguaeat  Size  in  Bytes  - Oecisal  naeber 
(anxious)  to  be  accepted  by  the  sabroatino. 

Baxiaaa  Function  Sise  in  Bytes  - Deciaal  aaaber 
(sax inns)  to  be  supplied  by  the  subroutine. 

Conversion  Subroutine  Type 

I - Input  conversion 
o • output  conversion 
B - Iaput/output  conversion. 

Arguaent  Bode  - For  input  data  to  the  subroutine. 

A - Alphaaeric  node 
B - Binary  node 
C - Coordinate  node 
0 - Deciaal  node 


Function  Bode  - One  of  the  characters  listed  in 
Puraaeter  (f)  defines  the  node  of  output  data  fron 
the  subroutine. 


Subroutine  Load  flodule  vase  - As  it  ex 
work  library,  this  aaae  east  be  the 
load  nodule  entry  point  sane.  This  naae 
sane  as  that  ased  in  paraaeter  (b) 
necessarily.  The  aaae  ased  say  sot  be  g 
seven  chnrncters  in  length. 

Bser  Base  - Vriter  of  the  subroutine, 
characters  say  be  ased,  sith  ao  eabed< 
*«riods  aay  be  ased  to  separate  initials 


3. 2 Job  Setap 

The  folloulag  stateaeats  : 
to  execute  the  ZSVBLDB  proced 
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//JOBMAHB  JOB  (standard  parameters) 

^ MBC  XS0BLDt,LIB=yoerlib,BODLIB-TEaP 

//SUB.SYSIB  00  • 

Control  statement  defining  sab root ins 
as  describsd  in  3.1. 

/* 

The  LIB  synbolic  pa rase ter  defines  the  library  where  the 
executable  subroutine  load  nodule  is  to  be  stored.  This  can 
te  a user's  private  library  or  an  Installation  lips  library. 

The  BOOLIB  synbolic  paraaeter  provides  the  work  library 
naae  where  the  subroutine  load  sodole  is  located. 

This  library  can  be  the  installation  prograa  library  or 

asseSnr  b]r  th*  subroutine  is 

asseabled,  link  edited,  and  tested  by  the  user. 

Saaple  Control  Stateaent 

SUBBT,  CTBIS,  02,  15,  0,  A,  A,  BOOBB,  OSERVAHE 

sta*«aent  defines  the  VIPS  subroutine  CTBIS 
as  an  output  subroutine  accepting  two  alpha  arguaent  bytes 
and  9*nerating  15  alpha  bytes  output.  The  load  nodule 
created  by  the  user  has  naae  and  entry  ooint  noouh. 
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Section  % 


DATA  COITBBSIOI 


Tkn  dntn  conversion  ntllitj  allows  the  aser/analyst  to 
convert  leio  FFS  data  bases  to  kps  360  fps  foraat.  kps 
3t»0  PPS  data  bases  can  be  reconverted  to  1«10  FPS  fornat. 
in  either  node*  the  conversion  process  produces  a logically 
identical  file  containing  all  of  the  appropriate  elesents  of 
intonation  for  the  node*  The  process  is  essentially 
autoaatic*  regairiag  the  analyst  to  provide  an  FFT  for  each 
ot  the  two  nodes  of  files*  but  reguesting  no  control  data. 

Data  conversion  occurs  at  the  field  level*  pernitting 
rearrangesent  of  data  eloaeats  within  a periodic  subset  or 
fixed  set*  lew  fields  nay  be  added  and  old  fields  nay  be 
dropped.  The  variable  set  (VSBT)  of  a 1*10  file  nay  not  be 
dropped  when  converting  to  n KPS  360  FFS  fornat. 
he positioning  of  the  data  fields  within  the  subset  or  fined 
f*1  pernits  change  of  the  record  control  group  contents. 
The  systea  senses  any  variation  in  the  segueace  of  the  new 

file  and  prints  an  error  sassage  vhen  the  file  aast  be 
S0  rt0d« 

1*10  node  coordinate  fields  are  autoaatically 
converted  by  the  systea  only  whan  the  length  specification 
in  the  1*10  fft  is  egaal  to  13.  Since  this  is  the  aoraal 
internal  foraat  for  1*10  data  bases*  no  problen  should 
result  fros  this  constraint* 


A listing  of  all  field  annas* 
will  be  printed  at  the  beg 
analyst  in  deterainiag  ana  file 


and  their  disposition* 
of  the  run  to  aid  the 

At  the  end  of  the 
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run,  a space  allocation  print-back  is  included  to  assist  in 
loading  the  data  base  onto  direct  access  devices.  The 
conversion  process  is  tape-to-tape  Shan  going  to  RIPS  360 
foraat  and  disk-to-tape  when  going  to  tke  1*10  foraat. 

DO  cards  used  in  the  utility  (OTDATAC)  are: 


SISIR 

DATAFILE 

PILS1410 

HEMFILB 

SISPBIMT 

SISOUT 


munama 

1*10  object  FFT 

360  ISAM  FFT  (and  data  base  if  360  to  1410) 
1*10  data  base  (optional,  see  below) 

Output  data  base  froa  conversion 
) 

) Printer 
) 


Direction  of  conversion  will  be  deternined  by  the  presence 
of  the  FILE1410  DO  card;  if  it  is  present,  the  conversion  is 
froa  the  1*10  to  the  360. 

Description  of  data  sets: 

SISIN  - 1*10  FFT  in  object  deck  fora. 

DATAFILE  - 360  ISAM  FFT/data  base. 

FILE1410  - 1*10  data  base,  usually  a 7-track,  556  bpi, 
even-parity  tape  with  nonstandard  labels.  The  following 
exanple  is  for  the  SOFA A data  base  which  is  cataloged  on 
the  360: 

//FILB1410  DO  DISP*OLD,DSMAHBkSOFAAZXX,LABEL*(,RSL) , C 
//  DCB= (DER*1,TRTCH*BT) 
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VBRFILB  - Output  filo  froa  tha  conversion  utility.  For 
the  1*10  to  300  conversion,  this  will  describe  a 
SAB  file  os  9-traek  tape. 

/IBHFILB  DO  OBIT-2 *00, 01  SP«(,CATL8)  ,DSBABB>SOF At 


For  the  360  to  1*10  conversion,  this  will  describe  a 
seven-track  tape  with  nonstandard  labels.  The 
BLKSISB  nest  be  supplied  in  the  DCB  paraaeters. 


//IEVFILB  DO  0iIT*2400-2,DISP* (, KEEP) , DSN ABB-SOFA AZXX,  C 

//  LABEL*!, ISL) ,DCB«(DBB*1,TBTCH=BT,BLKSIZE*270«) 

SISPIIBT  ABD  SI SOOT  - These  describe  the  systea  output 
writers. 


4.1  Data  Conversion  Utility  - 0TDATAC 

This  utility  will  convert  a 1*10  FFS  data  base  to  a BIPS 
360  FFS  data  base.  It  will  reconvert  a BIPS  360  FFS  data 
base  to  a BIPS  1*10  FFS  data  base. 


4. 1. 1 Procedure  I360COB 


This  procedure  sill  convert  a 1*10  FFS  data  base  to  a 
■IPS  360  FFS  data  base.  The  1*10  FFS  file  is  assaaed  to  be 
on  a 7-track  tape  and  the  aee  data  base  is  to  be  written  on 
a 9-track  tape.  Using  syabollc  paraaeters  for  this 
procedure,  one  eoeld  ase  the  following  JCL: 

//jobs abb  JOB  (standard  paraaeters) 

//  EXBC  X360COB, ISAB-aaaaaaa, VISA*-*  SBB-hhbbbh* , x 
//  FLl*10-ccccc,  Vl*l(K'SBB— dddddd  • , X 
//  3AB-eeeeeae,T3AB««SBl*ffffff « 

//S1SIB  DO  e 


(FFT  object  deck  of  1410  FFS) 
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•there 

aaaaaaa  = NIPS  360  FFS  ISAH  data  base  name  ou  disk 

bbbbbb  = disk  serial  nuaber  for  the  ISAH  data  base 

ccccc  - 1010  FFS  tape  data  base  naae 

dddddd  = tape  serial  aesber  for  the  1010  data  base 

eeeeeee  * NIPS  360  FFS  tape  data  base  naae 

ffffff  = tape  serial  nuaber  for  the  360  data  base. 


4.1.2  Procedure  X1010CON 

This  procedure  will  convert  a RIPS  360  FFS  data  base  to 
a 1010  FFS  data  base.  The  RIPS  360  FFS  data  base  is  assuaed 
to  be  on  a 2310  disk  pack  and  the  converted  data  base  is 
written  on  a 7-track  tape  with  nonstandard  labels.  Osing 
symbolic  paraaeters  for  this  procedure,  one  vould  use  the 
following  JCL: 

//JOBMAHE  JOB  (standard  paraaeters) 

//  EXEC  X10 1 0CON,I SAH«aaaaaaa, VISA H*f SER*  bbbbbb' , x 

//  SAH=eeeee, VSAH=*  SER*ff f fff • 

//srsiN  oo  * 

(1010  FFS  FFT  object  deck) 


/* 

where 

= NIPS  360  FFS  ISAH  data  base  naae  on  disk 

* disk  serial  nuaber  for  the  ISAH  data  base 

* data  base  naae  for  the  1010  FFS  tape 

* tape  serial  nuaber  for  the  1010  data  base. 


aaaaaaa 

bbbbbb 

eeeee 

ffffff 
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Section  5 

F IU  LOAD/ OSLO  AO  UTILITIES 


The  following  paragraphs  provide  tho  job  control 
language  and  necessary  information  required  to  transfer 
files  to  and  froa  the  Sequential  Access  and  indexed 
Sequential  Access  Bethods  (SAB  and  XSAB)  and  to  and  froa  the 
Sequential  Access  and  Virtual  Storage  Access  Hethods  (SAB 
and  VSAB).  These  utilities  are  effectively  automatic  and 
require  only  the  JCL  strean  for  control. 


5.1  SAB  to  ISAB  or  VSAB  Utility  - UT OLDISH 

This  utility  builds  an  BIPS  ISAB  data  base  or  a BIPS 
VSAB  data  base  froa  a HIPS  SAB  data  base.  Under  control  of 
tne  cc  synbolic  paraneter  on  the  BXBC  card  it  can  optionally 
build  the  ISAB  or  VSAB  data  basa  in  the  cospressed  and/or 
conpacted  fore  or  reverse  the  process  to  produce  the  ISAB  or 
vsab  data  base  in  the  standard  fora  (see  section  5.3). 

The  JCL  DO  cards  used  are: 

//DATAFILB  DD  Parameters  defining  the  nee  ISAB 

data  base 

//SAHFILB  OD  Parameters  defining  the  existing  SAB 

data  base 

//vsbfile  OD  Paraaeters  defining  the  nee  VSAB 

data  base. 

The  new  ISAB  HIPS  data  base  will  be  created  vith  the 
following  attributes:  aaster  index,  cylinder  overflow, 
independent  overflow,  delete  option,  write  check  and 
feedback  reorganisation  criteria. 
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The  procedure  XSTOIS  is  used  to  build  a NIPS  360  FFS 
ISAM  or  VS AN  data  base  froa  a NIPS  360  FPS  SAB  data  base. 

It  is  assuaed  that  the  existing  NIPS  SAB  data  base  resides 
on  a 9-track  tape,  and  that  the  ISAB  data  base  Mill  reside 
on  a 2314  disk  pack  with  a disposition  of  KBEP.  If  output 
is  to  be  a VSAB  data  base,  it  aust  have  been  previously 
ciefined  via  the  VSAB  service  routine  IDCANS  and  cataloged  on 
a VS AN  user  catalog.  Using  syabolic  paraaeters  for  this 
procedure,  one  would  use  the  following  JCL: 

//JOBNAHE  JOB  (standard  paraaeters) 

//  EXEC  XSTOIS, ISAH*aaaaaaa, 7ISAH=' SER-bbbbbb1 , 

//  PRINB=cc, IRDEX=d, SAN=eeeeeee, VS AB=* SBR=f f f f f f • , 

//  CC=gggggg 

/* 

where: 

aaaaaaa  = naae  used  for  the  new  ISAH  data  base 

bbbbbbb  = disk  serial  nuaber  for  the  new  ISAH  data  base 

cc  = nuaber  of  cylinders  of  priae  space  for  the  new 

ISAB  data  base 

size  of  index  needed  for  the  new  ISAB  data  base 

name  of  the  existing  SAN  data  base 

serial  nuaber  of  the  tape  that  contains  the 
existing  SAN  data  base. 

paraaeter  option  for  data  record  transforaation 
(CON PRESS,  CONPACT,  EXPAND  oc  both  CONPRESS  and 
CONPACT)  and  pad  record  suppression  (NOPAD) . 
Hultiple  values  aust  be  separated  by  coaaas 
and  the  whole  paraaeter  enclosed  in  single 
quotes,  (see  section  5.3). 

For  SAB  to  VS AN,  replace  the  ISAH  paraaeters 
with: 


d * 
eeeeeeee  = 
ffffff 

ggggqg 


VSCAT=aaaaaaaa, VSDSN=b bbbbbbb, NON VS B=* DUNN Y,  • 


utility  Support  (OT) 


where: 

aaaaaaaa  * naae  of  the  TSIN  user  catalog 

bbbbbbbb  3 naae  of  the  TSAH  data  base  to 
be  loaded. 

Nor nally,  after  the  file  has  been  copied  to  disk,  the 
leaaining  prise  space  will  be  filled  with  pad  records. 
These  are  ISifl  records  with  valid  keys  which  have  the  delete 
byte  set  on.  These  records  sake  it  possible  to  add  records 
to  the  end  of  the  file  daring  later  update  and  still  reaain 
in  the  priae  area. 

If  the  eser  does  not  want  these  pad  records,  he  nay 
include  the  NOPAD  keyword  in  the  synbolic  paraaeter  CC  on 
the  EXBC  card. 

An  exaaple  night  be  a SAD  file  that  is  daaped  to  disk 
for  use  with  TP.  In  this  case,  it  would  be  desirable  not  to 
pass  all  of  the  pad  records  for  a query,  while  the  user  is 
waiting  at  the  terainal. 

Upon  conpletion  of  UTBLDISH,  the  user  will  receive 
either  the  nessage, 

•NIPS  IS  AN  (TSAH)  DATA  FILE  HAS  BBBN  SUCCESSFULLY 

CHEATED* 

if  the  job  was  successful,  or  a OSBB  0200  ABEND  if  the  job 
was  unsuccessful. 


5.2  ISAB  or  TSAI  to  SAB  Utility  - UTBLDSAH 

This  utility  builds  a SAN  data  base  fras  either  an  ISAB, 
a vsab  or  another  SAB  data  base.  Bader  control  of  the  CC 
synbolic  paraaeter  oa  the  BXBC  card,  it  can  optionally  build 
the  output  SAB  data  base  in  the  coapressed  aad/or  coapacted 
fora. 

The  JCL  DD  cards  used  are: 
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//DATAFILE  DD  paraaeters  defining  existing  ISAM  data  file 
//VSHPILE  DD  paraaeters  define  existing  fSAH  data  file 
/ /SAMFILE  DD  paraaeters  defining  existing  SAH  data  file 

//SAHOUT  DD  paraaeters  defining  new  SAH  data  file 

The  procedure  XISTOS  is  used  to  build  a HIPS  360  FFS  SAH 

data  file  froa  an  ISAM  or  VSAN  data  file  or  copy  a NIPS  360 

SAM  data  file.  It  is  assuaed  that  the  existing  ISAM  data 
rile  resides  on  a 2314  disk  pack  or  that  the  existing  SAM 
cata  file  resides  on  a 9-track  tape  with  standard  label.  If 
input  is  a VSAH  data  file,  it  aust  be  cataloged  on  a VSAH 
user  catalog.  It  is  also  assuaed  that  the  output  SAH  data 
tile  will  be  written  on  a standard  label  9-track  tape. 

Using  syabolic  parameters  for  this  procedure,  one  would 
use  the  following  JCL: 

//JO BN AM E JOB (Standard  paraaeters) 

//  EXEC  XISTOS, ISAH=aaaaaa, ?ISAH=,SER=bbbbbbt , 

//  5AH=eeeeee, VS AM*  »SER=f f fff f » , CC=gggggg 

/* 

where: 

aaaaaa  = name  of  the  existing  ISAM  data  file 

bbbbbb  = serial  nuaber  of  the  disk  voluae  where  the 

ISAM  data  file  resides 

eeeeee  = name  used  for  the  new  SAM  data  file 

ffffff  * serial  nuaber  for  the  new  SAN  data 

file 

gggggg  = paraaeter  option  for  data  record  transforaation 
(COMPRESS,  COMPACT,  EXPAND  or  both  COMPRESS  and 
COMPACT  separated  by  a coaaa)  and  pad  record 
suppression  (NOPAD).  Multiple  walues  aust  be 
separated  by  coaaas  and  the  whole  paraaeter 
enclosed  in  single  quotes. 
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For  VSAfl  to  SAH , replace  the  ISAM  parameters  with: 

YSCAT=aaaaaaaa,TSDSI=bbbbbbbb 

where: 

aaaaaaaa  * name  of  TSAR  user  catalog 
bbbbbbbb  - naae  of  exisitng  TSAR  data  file. 

For  SAH  to  SAH  oae  would  use  the  following  JCL: 

//JOBMAHE  JOB  (Standard  paraaeters) 

//  BXBC  XISTOS,OLDSAH=aaaaaa,OLD VSAH=* SER=bbbbbb' , 

//  SAH*eeeeee,»SAH*'SBH*ff ffff • , PABH=gggggg 

where: 

aaaaaa  - naae  of  the  existing  SAH  data  file 

bbbbbb  = serial  nuaber  of  the  volune  where  the  SAH 
data  file  resides 

eeeeee  = naae  used  for  the  new  SAH  data  file 

ffffff  = serial  nuaber  for  the  new  SAH  data  file 

999999  - paraaeter  option  for  data  record  transforaation 

(CORPBBSS,  COHPACT , BXPAID  or  both  COHPHESS  and 
COIPACT  separated  by  a coaaa).  Multiple  values 
aust  be  separated  by  coaaas  aad  the  whole  paraaeter 
enclosed  in  single  quotes,  (see  section  5.3) . 

Keywords  in  the  PABH  are  used  to  designate  the  fora  of 
the  output  SAH  data  base  irrespective  of  the  fora  of  the 
input  is AH,  SAH  or  TSAR  data  base.  The  keywords  for  the 
PABH  and  their  iaplicatioas  are  the  saae  as  those  for  the 
SAH  to  ISAH  utility. 

Upon  successful  coapletion  of  OTBLDSAfl,  the  user  will 
receive  the  aessage: 

•NIPS  SAH  DATA  FILE  HAS  BEEN  SUCCESSFULLY  CHEATED' . 
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Prior  to  termination  of  the  utility,  it  will  print 
statistics  that  are  beneficial  for  the  oser/analyst. 

The  first  line  of  statistics  printed  gives  the  file 
name,  volume  serial  number,  date,  time,  and  page  number. 

Then  information  is  printed  concerning  the  sets. 

There  are  seven  columns  of  information  displayed,  with 
headings,  as  follows; 

a.  SET  The  first  entry  is  "FIXED  SET"  and  following 

is  each  periodic  set  with  the  number  specified 
in  the  FPT. 

b.  MINIMUM  Shows  the  size,  in  bytes,  of  the  smallest  subset 

SUBSET  within  the  specified  set,  fixed  or  periodic.  If 

SIZE  a variable  field  is  specified,  the  minimum  and 

(BYTE)  maximum  size  will  not  be  the  same. 

c.  MAXIMUM  Shows  the  size,  in  bytes,  of  the  largest  subset 
SUBSET  within  the  specified  set,  fixed  or  periodic. 

SIZE  If  a variable  field  is  specified,  the  min- 

(BYTES)  imum  and  maximum  size  will  not  be  the  same. 


d. 


e. 


f. 


NUMBER  OF 

SUBSETS 

PER  DATA 

RECORD 

MINIMUM 

HAXNIMUM 


These  two  columns  reflect  the  minimum  and 
maximum  number  of  subsets  within  a periodic 
for  the  total  record.  The  fixed  set  would  be 
1 for  minimum  and  maximum.  The  absolute 
minimum  for  periodics  would  be  9 and  the 
maximum,  any  variable  number. 


TOTAL 

NUMBER 

OF 

SUBSETS 


The  total  number  of  subsets  in  each  periodic 
set  for  the  entire  file  is  printed  here. 

The  number  printed  for  the  fixed  set  is  the 
total  number  of  data  records  in  the  file. 


SIZE  OF 
LARGEST 
SET 


This  field  shows  the  maximum  size  in  bytes 
of  the  indicated  set  for  any  record  in  the 
file. 
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Foe  the  ISAH  file,  the  above-mentioned  statistics  are 
printed  along  with  information  on  t he  organization  of  the 
ISAM  file. 

The  number  of  PBIHE,  OVEBPLON,  DELETE,  and  PAD  records 
is  calculated  and  printed.  Also  information  froa  the  DSCB 
is  printed.  The  DSCB  information  concerns  the  INDEX,  PBIHE, 
and  OVER PLOW  cylinder/track  allocation  and  usage.  The 
column  headings  are  "CTL/TRACKS  ALLOCATED,"  "TRACKS 
UTILIZED,"  and  " PBRCENT  TRACKS  UTILIZED. " The  number  of 
tracks  in  each  cylinder  overflow  area  is  also  provided. 
With  this  information  the  user  can  calculate  the  aaoant  of 
space  needed  for  his  job.  This  alleviates  unnecessary  pad 
records  that  are  added  if  any  prime  area  regains. 

5. J Compression  and  Compaction  of  Data  Records 

Compression  and  compaction  provide  a means  for  the 
re ’ruction  of  intermediate  storage  requirements  for  data 
without  altering  the  integrity  of  the  data.  This  data 
reduction  scheme  is  particularly  suited  to  data  files  that 
contain  strings  of  identical  characters  or  a large  guantity 
alphabetic  data. 

i string  of  identical  characters  is  compressed  by 
tea.  , '.ting  it  to  two  bytes.  The  first  byte  is  a control 
*yt‘.  which  indicates  that  compression  has  been  applied  and 
a count  of  the  nunber  of  identical  consecutive  bytes 
i.icit  were  in  the  original  string.  The  second  byte  is 
identical  to  those  in  the  original  string. 

a string  of  alphabetic  characters  is  coapacted  by 
'nsiating  it  to  a control  byte  followed  by  a string  of 
- l°d  characters.  The  coetrol  byte  indicates  that 

?vpaction  has  been  applied  and  gives  a count  of  the  coded 
v-racters.  Each  coded  character  represents  a conbination 
oe  two  adjacent  alphabetic  characters. 

other  NIPS  components  recognize  coapressed/cpapacted 
a and  expand  it  prior  to  processing.  File  flaintenance 
4 fl ) will  recoapress  and/or  recompact  an  updated  record 
1.  afore  writing  the  record  to  the  data  file. 

Compression/coapaction  offers  reduction  in  I/O  time  and 
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space  requirements  for  the  data  file  at  the  expanse  or 
processing  overhead. 

Keywords  in  the  PARH  parameter  (specified  by  the  CC 
symbolic  pacaaetec)  are  used  to  designate  the  fora  of  the 
output  ISAM  or  VS  AM  data  base  irrespective  of  the  fora  of 
ne  input  SAH  data  base.  The  Keywords  for  the  PARH  and 
their  inplications  are  as  follows: 


COMPRESS  - 


compression  is  applied  to  the  output  data 
records. 


COHP ACT 


COHPRESS,  - 
COMPACT 


EXPAND 


compaction  is  applied  to  the  output  data 
records. 

a combination  of  coapression  and  coapaction 
is  applied  to  the  output  data  records. 

compression  and/or  compaction  is  reversed 
to  produce  standard  fora  data  records. 


If  none  of  the  parameters  is  specified,  no  data 
transformation  takes  place,  i.e.  the  output  ISAM  or  VSAH 
data  base  form  will  be  the  same  as  the  input  SAH  data  base 
form. 
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The  utility  prograa  DTQtTQDF  allows  tho  aser/aaalyst  to 
create  a NIPS  360  PPS  data  fils  froa  the  aasaor  file 
(QBT/QDF)  prodacad  by  tbe  retrieval  processor  (HASP).  The 
output  froa  this  utility  rua  is  a segueatial  access  aathod 
(SAB)  file  which  is  identical  to  a file  generated  using  the 
file  naiatenaace  processor.  The  copy  process  is  coaplete, 
carrying  forward  all  of  the  logic  stateaeats  associated  with 
the  original  file  as  well  as  the  PFT. 


6.1  laput 

Input  for  the  cataloged  procedure  XQRTQDP  coses  froa  two 
sources.  The  first  source  is  the  paired  data  sets,  QBT  and 
vDP  which  are  the  noraal  output  of  ItiSP.  The  job  setup 
description  provides  the  proper  assigaaeat  of  these  data 
sets  to  the  utility.  The  second  source  is  a single  control 
card.  This  control  card  is  free  foraat,  in  that  the 
paraaeter  string  aay  be  initiated  in  any  card  coluan,  and 
the  paraaeters  are  separated  by  blanks  or  coaaas.  Only  one 
control  card  is  peraitted  for  each  execution  of  the  utility. 
The  paraaeters  provided  on  the  control  card  are  either  one 
cr  two  keywords  and  their  corresponding  operands.  The  first 
keyword  is  QOBBTIO*.  This  keyword  aay  be  eatered  in  aay  of 
tae  following  fora s: 


aid  aust  be  inaediately  followed  (ao  intervening  bleak)  by 
tae  retrieval  auaber  (answer  identification  auaber) 
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specified  in  the  retrieval  run  creating  the  answer  data 
sets.  The  guery  nunber  is  United  to  four  digits  in  size. 
Leading  zeros  nay  or  nay  not  be  included  in  the  aunber. 

The  second  keyword  paraaeter  is  BITIP*,  and  nay  be 
entered  in  any  of  the  following  foras: 

HITID* 


R= 

,\V  ' ' V. 

and  aust  be  inediately  followed  by  the  report  instruction 
table  identification  (HITID) . This  keyword  and  its  operand 
nay  be  onitted  if  the  specific  answer  set  desired  did  not 
use  the  RITID  parameter  for  identification  in  the  original 
filSP  run. 

:V>-  > - ■ -'v* 

The  following  exaaples  indicate  the  types  of  control 
stateaents  expected  by  the  processor.  First,  an  exaaple  of 
the  input  required  to  identify  retrieval  aunber  (query 
aunber)  3 of  a batched  retrieval  run,  but  with  no  BITID 
specified  in  the  retriever  input  stcean: 


Bestricti ons 


The  user  nay  not  attenpt  to  output  a data  file  froa  an 
answer  strean  forned  under  the  following  conditions: 


HASP  execution  was  a nultifile  run. 


QUERYH0=3 

or 

QUERY  110*000  3 
or 

QUEBYRO*003  RITID* 

Second,  an  exaaple  of  the  use  of  the  BITID  stateaent: 
QUERY  110=3  RITID=UN AHEIT 
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b.  A sort  has  specified  for  tbs  usm  sot  identified. 

c.  Hultiplo  IP  condition  state neats  soro  iscladod  is 
tho  retrieval  auaber/BXTXD  idoatifiod  assvor  sot. 

d.  Hultiplo  SBLBCT  statoooBts  sore  iscladod  ia  the 
retrieval  auabor/BITIO  idoatifiod  aasvor  sot. 

Any  batched  retrieval  coaditioa  that  vould  cause 
re sequencing  of  tho  rosaltaat  aasvor  set.  or  aay  retrieval 
coaditioa  that  voald  cause  duplicate  output  records 
idoatifiod  by  a cob bob  retrieval  aaaher/lXXXD  aay  a at  be 
used  to  create  a file  through  the  use  of  this  utility. 


6. 3 Job  Setup 

The  follow!*?  stateaoats  illustrate  tho  job  setup  used 
to  execute  tho  XQBTQDP  procedure: 

//  BXBC  RASP,  paras et or s for  user's  file 

//BASP.SfSIB  DD  * 

(HASP  state aest  conforaing  to  rales  outliaed 
uador  6.1  for  aasser  set  to  be  processed  by 
VTQBTQDF) 

/• 

//  BKBC  XQBTQDP, SAH>BTFILB 

//QBTQDP  . ST  SI  ■ DD  • 

(Coatrol  stateaeat  defiaiag  iaput  as 
described  ia  d.1  aad  7.1.1) 

/• 


The  user  obtaias  his  aev  data  file  (HTFILB)  os  a 
standard- la be led,  Detract  tape  arittea  according  to  the 
installatioa  assigaed  density.  The  user  aay  override  the 
syabolic  paraneters  to  obtain  input  aad  output  data  sets 
differing  froa  the  procedure-specified  standards. 

. . ■ 

The  XQBTQDP  procedare  aay  be  executed  ia  a separate  job 
froa  the  BASP  if  the  QBT  aad  QDP  are  saved.  In  this  case, 

A 
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the  QRTFILE  and  QDFILE  symbolic  parameters  would  ba ve  to  be 
specified  with  the  appropriate  values. 

6.4  Error  Conditions  and  Processing 

All  error  conditions  sensed  by  this  progras  will  cause 
termination  with  a "user"  abnormal  end  code  of  1,  2,  or  3. 
These  codes  are  always  accoapanied  by  an  error  aessage 
uniquely  identifying  the  error  condition  encountered.  The 
iolx  wing  material  is  included  as  a quick  reference  of  error 
listings.  For  full  meaning  of  the  error  messages,  see 
Volume  IX,  Brror  Codes. 

INVALID  KEY  WORD  - RUN  TERMINATED 

NO  ANSWER  SET  TOR  QU3R YNO/BITID 

QRT/QDF  IS  MULTIFILE  PRODUCT  - ERROR 

NO  FILE  RECORD  ON  QRT  - BAD  INPUT 

ONLY  ONE  CONTROL  CARD  PERMITTED 

BAD  RECORD  TYPE  FOUND  - BUN  TERMINATED 

EOD  POUND  COPYING  FFT  AND  LS  - NO  DATA 

USER-SPECIFIED  SORT  - CAN'T  PROCESS 

MULTIPLE  IP/SBLECT  STATEMENTS  USED  WITH 
QUERY/RITID  SPECIFIED  - RON  ABORTED 

ERROR  READING  QRT  - ERROR  ABEND 

PHYSICAL  EODAD  ON  QDF  - ERROR  ABEND. 

NO  RECORD  FOUMD  - RUN  TERMINATED 

IECID  SPECIFIED  IN  QRT  CANNOT  BE  FOUND 
IN  QDF 

NARNING  - THIS  FILE  BUILT  FROM  QRT/QDF 
WITHOUT  AN  FPT 
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Suction  7 

UTSUBCHK 


The  UTSUBCHK  utility  can  be  need  to  check  out  user* 
written  subroutines  (ALC,  FOBTBAB,  COBOL)  uritten  to 
supplenent  SIPS  applications.  SOBCHBCK  links  to  the  user- 
designated  subroutines  stored  as  a neuber  os  a partitioned 
data  set  in  load  fora,  prints  user  run  specif icatioss, 
prints  subroutine  input  and  output,  and  relates  the  sucoess 
of  the  subroutine  for  each  user  input. 

UTSUBCHK  siuulates  the  call  initiated  by  the  various 
HIPS  application  nodules.  The  conditions,  described  in 
Voluae  I,  Introduction  to  Pile  Concepts,  Developnent  of 
Conversion  Subroutines,  are  duplicated. 


7.1  Input 

Input  to  SUBCHBCK  is  on  punched  cards.  The  first  card 
in  relates  the  run  control  paraaeters  as  follous: 

MILS  BUCtlaUfll 

1-8  (BEQUIHED)  User  subroutine  nane,  left- justified  with 

trailing  blanks  as  required. 

10  (OPTIONAL)  Blanks  - Alpha aerie  input;  do  not  convert. 

B - Convert  data  to  binary  prior  to  sub- 
routine link. 


12-14  (OPTIONAL) 
(fixed  length 
arguaent) 


A 3-digit  "unber  {use  leading  zeros 
if  necessary) . 
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If  col  tun  10  contains  a "B",  nuaber  * 
length  of  data,  starting  in  colnan  1 
of  data  cards,  to  get  and  convert. 


7.2  Functioning  and  Restrictions 

If  the  card  contains  only  the  subroutine  nane,  UTSOBCHK 
Mill  assune  variable  length  data  input  (not  to  exceed  80 
bytes  in  length)  with  no  conversion  to  binary  required.  In 
this  case  the  argunent  length  is  deterained  by  a scan,  right 
to  left,  of  each  data  card  for  the  first  aonblaak  character. 
If  binary  conversion  is  required,  the  resultant  arguaent 
will  be  one  full  word  in  all  cases. 

All  user  data  cards  follow  the  control  card.  The  data 
used  for  the  arguaent  aust  start  in  coluan  1.  To  allow  for 
trailing  blanks,  the  fixed  length  entry  in  control  card 
coluans  12  through  14  can  be  used. 

The  paraaeter  list  built  starts  with  a half-word 
containing  the  binary  length  of  the  arguaent.  A 256-byte 
internediate  work  area  is  set  up  for  the  arguaent  and 
function,  contiguous  to  this  length  entry.  This  aeans  that 
while  either  the  arguaent  or  the  function  length  nay  be  up 
to  255  bytes,  the  sun  of  their  lengths  aust  be  less  than  or 
equal  to  256  bytes. 

The  entire  input  (unconverted)  argunent  is  printed  out 
for  each  data  card.  Iaaediately  following  each  of  these 
entries,  the  subroutine  output  and  results  follow 
respectively. 

Because  the  input  can  be  up  to  255  bytes  several  input 
cards  night  be  required  for  each  input  arguaent.  For  fixed 
length  arguaents  the  sane  nuaber  of  input  cards  are  required 
for  each  arguaent  (i.e.,  for  a 173-byte  arguaent  three  data 
cards  are  required  for  each  arguaent  - use  blank  cards  as 
filler  if  necessary). 
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7.3  Job  Sot  up 

Tho  following  stmtoannts  illustrato  tho  job  sotup  used 
to  exocnto  tbo  XSOBCBK  procodnre: 

//  BXIC  XSUBCHE, LIB-TEST E» 

//SOBCBK. STSXB  DO  • 

(Control  card  dofining  inpat  as  dnscribnd  in  7.1) 

data  card(s) 

/* 

The  LIB  syabolic  para not ar  dofinos  tbs  partitionsd  data  sat 
where  the  subroutine's  executable  load  nodulo  is  stored. 
The  library  need  not  be  n BZPS  file  library#  but  it  should 
have  the  sane  DCB  attributes, 

Saaple  Control  Card 

HTSOB  099 

Saaple  data  cards  in  the  above  case 

Col  80 

12345678901QPT86789ABCB  123798 

7890567893BCBDBFOBQ 

1379654 32 1BDLC88789BFQC  589324 

843297684 ShPQDBYQHQ 
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Section  8 
OTDHPLIB 


The  utility  prograa  OTDHPLIB  allows  the  user/analyst  to 
print  the  naees  of  reports  and/or  logic  stateaents 
associated  with  a HIPS  360  FFS  data  file.  The  output  froa 
this  utility  is  a foraatted  listing.  The  input  data  file 
nay  be  in  Seguential  Access  Method  (SAB),  Indexed  Sequential 
Access  Method  (ISAM)  or  Tirtual  Storage  Access  Method  (VSAB) 
fora. 

3.1  Input 

Input  for  the  cataloged  procedure  XDHPLIB  consists  of 
the  user*s  file  (SAM,  ISAM  or  VSAH)  and  a single  control 
card.  The  control  card  is  in  a fixed  foraat  in  that  it  aust 
begin  in  card  coluan  1 and  paraaeters  aust  be  separated  by 
coaaas.  The  control  card  is  to  be  prepared  as  follows: 

PBIMT*  BBPOBT, XXXXIXX 

* 

where  XXXXXXX  will  contain  one  of  the  following  paraaeters: 

ALL  - provides  a listing  of  all  report 

naaes  and  all  logic  stateaents. 

LIST  - provides  a list  of  all  report  naaes. 

(Beport  ID)  - provides  a listing  of  all  logic  state* 
aent  naaes  for  the  report  ID  specified. 


3.2  Job  Setup 

The  following  stateaents  illustrate  the  job  setup  required 
to  execute  the  XDMPLIB  procedure: 


k 


//  EXEC  XDHPLIB, ISAH=TESTEH 

//UTDHP.S  YSIN  DD  * 

PRINT, REPORT , ILL 
/* 

The  preceding  exanple  lists  all  report  and  statenent 
nanes  on  a cataloged  ISAM  data  set  naned  TESTER. 


//  EXEC  XDHPLIB, ¥SCAT=*  NIPS. CAT* , ISAH*' VS AH.TESTER* 
//DTDHP. DATAFILE  DD  AHP3"AHORG • 

//OTDHP.STSIH  DD  * 

PRINT, REPORT, ALL 
/* 

The  preceding  exanple  lists  all  report  and  statenent 
nanes  on  the  VSAH  file  TSAH. TESTER  cataloged  on  NIPS. CAT. 

//  EXEC  XDHPLIB, I SAH^ TESTER, ?IS  AH= ' S ER*PPSLIB* 

//UTDHP.S IS IN  DD  * 

PRINT, REPORT, BEPTA 
/* 

This  exanple  lists  associated  logic  statenent  nanes  for 
a report  entitled  REPTA  included  in  the  uncataloged  ISAH 
data  set  TESTER  residing  on  a 2314  voluae  labeled  PPSLIB. 

//  EXEC  XDHPLIB, SAH=TESTER, VS AH=*SER=N12345* 

//UTDHP.S TSIN  DD  * 

PRINT, REPORT, LIST 
/* 

The  preceding  exanple  provides  a listing  of  all  report 
nanes  contained  within  the  data  set  TESTER  which  resides  on 
a 9-track,  800  bpi  tape  with  the  volune  serial  nuaber  of 
N12345. 

The  XDHPLIB  procedure  nay  be  executed  in  a separate  job 
or  as  a step  of,  for  exanple,  an  PH  update.  It  is  to  be 
noted  that  all  routines  used  in  conjunction  with  the 
execution  of  this  procedure  reside  on  FPS.JOBLIB. 
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Section  9 
UTCLASS 


rhe  prograa  UTCLASS  provides  the  user  with  the 
capability  of  changing  the  classification  of  a MIPS  360  FPS 
ISAM,  SAM  or  VS AM  file.  A single  card  is  required  which 
will  contain  only  the  new  classification  of  the  file. 


9.1  Input 

The  prograa  UTCLASS  requires  a single  input  card 
containing  the  new  classification  of  the  data  file.  The 
card  is  free  fornat  and  the  new  classification  will  be  left- 
justified  with  trailing  blanks,  if  reguired,  when  written 
out  to  the  file.  The  length  of  the  classification  field  is 
32  characters  and  truncation  will  be  perforaed  to  the  right. 

To  change  classification  of  the  file  to  blanks,  that  is, 
no  classification,  the  input  card  nust  contain  at  least  one 
blank  enclosed  in  apostrophes.  This  is  the  only  case  in 
which  an  apostrophe  which  is  entered  on  the  input  card  does 
not  becone  part  of  the  actual  file  classification.  *' 


9.2  Output 

Two  outputs  are  produced  by  a successful  run  of  this 
prog ran: 

a.  The  updated  data  file  containing  the  new 
classification. 

b.  A listing  on  the  printer  indicating  successful  or 
unsuccessful  updating  and  the  new  classification  if 
successful. 
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9*3  Job  Setup 

The  following  statements  illustrate  the  deck  setup  used 
to  execute  the  OTCLASS  procedure. 

//  EXEC  XCLASS, ISAH=TESTER, 

//  TISAB**  SEB»PFSLIB* 

//CLASS. STSII  DD  * 

(Oser-supplied  card  containing  new 
classificat  ion) 


/* 

The  preceding  exaaples  will  change  the  classification  on 
an  uncataloged  ISAB  file. 

//  EXEC  XCLASS#SAH=TESTER,VSHOOT=' SER=TSTVOL» , 

//  SAHOOT= 

(Oser-supplied  card  containing  new 
classificat ion) 

/* 

The  preceding  exaaple  will  change  the  classification  of 
a cataloged  SAB  file  on  tape. 

//  EXEC  XCLASS, SAH»TBSTEH, 

//  0SAB«2314,¥SAH»*SEE=FPSLIBt 

//CLASS.S YSIM  DD  * 

(Oser-supplied  card  containing  new 
classification) 


/* 

The  preceding  exanple  will  change  the  classification  on 
an  uncataloged  SAB  file  on  disk. 
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//  EXEC  XCLASS,VSCAT=*  UPS. CAT*, ISAM=*VSAH.  TESTER* 
//CLASS. DATAFILE  DD  AHP=*AHORG* 

//CLASS. STSIM  DD  * 

(user-supplied  card  containing  new  classification) 

/* 

The  preceding  exaaple  will  change  the  classification  of 
the  VS AH  file,  VSAH. TESTER,  cataloged  on  MIPS. CAT. 
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Section  10 

SOURCE  LANGUAGE  STORAGE 


Source  programs  for  NIPS  coaponents  nay  be  stored  on  a 
library  to  facilitate  housekeeping  and  program  aaintenance. 
Maintaining  a library  will  ensure  that  a single,  current 
version  o f the  source  program  is  always  available.  The 
Source  Program  Library  can  be  updated  by  batch  jobs,  or  by 
the  EDIT  component  if  on-line  terminals  and  the  NIPS  TP 
component  are  available.  EDIT  capabilities  are  described  in 
Volume  VI  of  the  NIPS  User  Manuals,  Terminal  Processing 
(TP)  . 


10.1  Source  Libraries 

Two  types  of  libraries  can  be  utilised  for  storage. 
Both  types  are  direct-access  partitioned  data  sets.  The 
first  type  of  library  is  normally  used  to  store  80-character 
card  images.  This  library  is  similar  to  a Procedure  or 
Macro  Library  and  has  fixed  length,  80-character  records, 
normally  blocked  to  an  efficient  blocksize  which  is  a 
multiple  of  80. 

The  second  type  of  library  is  the  Pile  Library.  This 
library  has  records  of  undefined  length  and  is  normally  used 
to  store  the  compiled,  executable  NIPS  user  programs 
(Retrievals,  PITs,  etc.).  Source  programs  will  be  stored  on 
this  library  in  800-character  blocks,  containing  10  card 
images  each.  OS  utilities  may  not  be  used  to  modify  source 
on  this  type  of  library,  but  MIPS  coaponents  nay  as 
discussed  below. 

Each  source  program  member  stored  on  a library  by  a NIPS 
language  component  or  utility  will  contain  an  indicator  as 
to  which  MIPS  language  conponent  (RASP,  PH,  etc.)  is 
involved.  This  will  enable  a terminal  user  to  scan  a 
library  for  RITs,  logic  statenents,  etc. 
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10.2  Means  of  Storing  Source 

Fro®  the  batch,  source  programs  aay  be  stored 
library  by  either  of  two  isaans.  The  NIPS  coaponent  wl 
coupiles  the  source  progras  can  be  reguested  to  place 
source  on  a specified  library,  or  the  progr&a,  UTSOURC, 
be  executed  as  a stand-alone  utility. 


10.  3 


Conditions  of  Source  Library  Update 


Source  will  be  stored  on  a library  by  the  UTSOUHC 
utility  and  the  NIPS  language  coaponents  if  the  following 
two  conditions  are  set: 

a.  A DO  statement  specifying  the  user's  library  and 
having  a DDNAKE  of  SOURCLIB  is  present  in  the  job 
step  JCL. 

b.  A source  control  card  is  placed  iaaediately  in 
front  of  the  source  prograa  in  the  input  stream. 

The  SOURCLIB  DD  stateaent  is  included  in  each  NIPS 
piocedure  which  allows  coapilation  or  structuring  of  source 
material.  It  is  also  included  in  the  XUTSOORC  procedure 
which  executes  the  UTSOUFC  utility.  The  user's  library  naae 
is  specified  through  use  of  sysbolic  parameters. 


10.4 


Source  Control  Statement 


The  source  control  card  follows  the  general  foraat  of 
I23UPDTE  utility  control  cards.  Any  Runber  of  blanks  aa y 
separate  the  fields.  The  format  is  as  follows: 


ADD 
RE  PL 
DELETE 


The  ./ 
characters 
st  atenen  t. 


[NAME  = ixxr] 


must  be  coded  in 
identify  this 


?S  OP 

F8  QUIP 

RASP 


coluans  1 
card  iaage 


and  2.  These  two 
as  a source  control 
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Either  ADD,  BEPL,  or  DELETE  »ust  be  coded  if  RARE  is 
coded.  ADD  says  that  this  is  a new  source  aenber  that  is  to 
be  added  to  the  library.  If  a aeaber  already  exists  with 
the  sane  naae,  a diagnostic  aessage  will  be  printed,  and  no 
library  action  will  take  place.  BEPL  will  replace  a aeaber 
on  the  library  with  the  aew  source  which  follows  the  control 
card.  If  no  aenber  presently  exists  with  the  sane  naae,  it 
will  be  added.  DELETE  will  delete  the  aeaber  with  the  naae 
specified. 

MARS  gives  the  naae  of  the  source  prograa  assigned  by 
the  user.  The  naae  aust  follow  standard  OS  360  rules  for 
library  aeaber  naaes  and  nay  be  np  to  eight  characters  in 
length. 

The  last  operand  on  the  control  stateaent  is  used  to 
specify  the  RIPS  coaponent  to  which  the  source  nuaber  is 
related.  That  is,  a source  BIT  will  have  OP  coded  in  its 
soarce  control  stateaent.  This  field  is  optional  when  a 
MIPS  language  coaponent  is  used  to  update  a source  library 
since  the  appropriate  coaponent  ID  will  autoaatically  be 
included.  It  aust  be  included  if  the  stand-alone  utility  is 
used  and  NIPS  source  aaterial  is  being  stored.  If  other 
data  is  being  stored,  the  4 -byte  value  entered  is  copied  so 
that  classes  of  data  can  be  accessed  by  EDIT. 

The  existence  of  a source  control  card  containing  no 
operands  (blank  except  for  ./  in  coluans  1 and  2),  will 
signal  the  end  of  a source  aeaber  and  can  be  used  when 
additional  source  aaterial  exists  that  will  not  be  added  to 
the  library. 


10.5  Source  Renber  Manes 

The  naae  given  to  the  source  on  the  source  control  card 
does  not  have  to  be  the  sane  as  that  assigned  on  the  TITLE, 
create,  or  ADD  statenent  card  within  the  source.  It  is 
suggested  that  the  user  adopt  a naaing  convention  such  as 
adding  an  S suffix  to  the  naae  of  the  MIPS  prograa.  This 
will  provide  a ready  recognition  of  the  source  aenber. 
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10.6  Operation  of  Source  Library  Update 

The  input  streaa  to  a VIPS  language  component  or  the 
utility  nay  consist  of  one  or  acre  source  prograus  to  be 
stored  on  a library.  The  library  action  reguested  by  the 
source  control  cards  is  perforaed  as  the  input  streaa  is 
read  initially.  Xo  library  action  is  taken  on  data  in  the 
input  streaa  until  a source  control  card  is  encountered.  If 
the  control  card  specifies  a delete  action,  it  is  perforaed 
iaaediately  and  reading  of  the  inpot  resunes.  If  an  ADO 
stateaent  is  encountered,  the  library  is  checked  for 
existence  of  a aeaber  with  the  sane  nane.  If  one  is  found, 
a diagnostic  is  printed,  and  no  library  action  is  taken  with 
that  aeaber.  If  a duplicate  aesber  nane  is  not  found  or  a 
BEPL  action  is  specified,  the  following  cards  of  the  input 
streaa,  up  to  the  next  source  control  card  or  end  of  input, 
are  placed  on  the  library  and  given  the  aeaber  nane 
specified. 

When  using  a IIP S language  coaponent  to  update  a source 
library,  the  source  control  cards  will  not  be  passed  to  the 
language  translator  phases  and  will  thus  not  interfere  with 
noraal  compilation  or  action  of  HIPS  coaponent s. 


10.7  Sequencing  of  Source  Material 

All  source  aaterial  that  is  added  to  a library 
sequenced  in  colunns  73-80  and  printed  during  t 
action.  If  a HIPS  language  coaponent  is  being 
newly  sequenced  source  will  be  passed  to  th< 
translator  phase. 


10.8  Listing  Source  Library  Members 

The  UTSOORC  utility  aay  also  be  used  to 
aeaber  froa  a source  library.  This  is  do 
the  library  using  symbolic  parameters  and 
aenbers  to  be  listed  using  the  PABH  value. 
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10.9  Job  Sotap 

If  a UPS  laagaage  coapoaeat  is  used,  tho  procedare 
coataias  tho  S001CLIB  DO  statoooot.  Spoclf j tho  uh  of 
row  library  through  use  of  tho  a ya  bo  lie  paraaotors  aa 
outliaod  la  Tolaao  Till,  Job  Preparation. 

Tho  iapat  stroaa  aay  bo  a ooabor  ia  yoar  library*  If 
so#  uso  tho  ayabolic  paraaotor  un  to  s pacify  tho  aoabor 
aaao.  Othoraiao  override  tho  XUTSODBC  STSIB  DD  atatoaoat  to 
define  tho  iapat  stroaa.  Dote  that  STSIB  is  igaored  for 
list  faactioas. 

If  tho  stand-alone  etility  is  used,  tho  folloaiag 
stateaents  illastrato  tho  dock  sotap  asod  to  aadato  a source 
library: 

//JOBiiHB  JOB  (Iastallatioa  Paraaotors) 

//jo blib  dd  (Iastallatioa  JOBUB  Paraaotors) 

//OPD  SI SC  XUTSOUBC,SOUBCL*IOOBLIB 

//SOUBC.  STSII  DD  * 

source  control  stateaents  and  soarco  aeabers 

/* 

The  folloaiag  stateaents  illastrato  tho  dock  sotap  asod 
to  list  a aoabor  froa  a source  library: 

/ / jobhahe  job  (Iastallatioa  Paraaotors) 

//jo BLIB  DD  (Iastallatioa  JOBUB  Paraaotors) 

//LIST  EXBC  XUTSODBC, SOOBCL»TOOBUB,Piaa.  90  OBOSBCBM 
/* 


rr  - 
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IIDBX  SPECIFIER 
(UTNDXSPC) 


The  Index  Specification  utility  allows  a user  to  specify 
indexing  inforaation  for  a data  file  without  running  a File 
Structure  or  File  Haintenance  job.  The  user  can  add  and 
delete  indexes  in  the  sane  run.  For  each  index  added,  all 
inforaation  necessary  to  aake  that  index  operational  is 
generated  and  placed  in  the  Index  Data  Set. 


Any  fixed-length  field  defined  in  the  file  nay  be 
specified  as  a secondary  index.  Any  variable  field, 
variable  set  or  fixed-length  alpha  field  defined  in  the  file 
nay  be  specified  as  a keyword  index.  A fixed-length  field 
aay  not  be  specified  as  both  a secondary  and  keyword  index. 


UTNDXSPC  acts  as  the  driver  to  perform  the  functions  of 
calling  Index  Specification  to  insert  or  delete  Index 
Descriptor  Records  in  the  data  file,  and  of  executing  Index 
Haintenance  to  correlate  the  Index  Descriptor  Records  in  the 
data  file  with  the  Index  Control  Records  in  the  Index  Data 
Set  and  to  update  the  latter  accordingly.  UTNDXSPC  operates 
on  an  ISAM,  SAM  or  VSAfl  data  file. 


11.1  UTNDXSPC  Input 


UTNDXSPC  accepts  SOB/TAB  and  INDEX  statements  as  input. 
These  statements  aust  be  subaitted  through  the  STSIN  device. 
Further  discussion  of  Index  Specification  aay  be  found  in 
Voluae  II,  File  Structuring. 


11.1.1  SUB/TAB  Card 


A SOB/TAB  card  is  used  to  describe  a subroutine  or  table 
to  be  used  by  secondary  indexing.  A subroutine  or  table  nay 
be  a conversion  routine,  to  convert  data  froa  an  internal 
data  file  foraat  to  a separate  index  foraat.  On  the  other 
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hand,  a sub routine  or  table  nay  bo  an  analyser  routine, 
designed  to  analyse  tbe  pnraneter  list  of  a FUBCTIOI 
operator  to  deteraiae  iades  usage  and  provide  a list  of 
values  for  index  gualif lent ion. 

For  a keyword  iadesed  field,  a subroutine  or  table 
defines  options  that  direct  the  selection  of  kejaord  values. 
It  nay  designate  a stop  sord  table  shich  is  a list  of 
irrelevant  (noise)  words,  a dictionary  shich  is  a list  of 
all  non-literal  keywords,  or  a user  scan  routine,  shich  is 
a subroutine  provided  by  the  user  to  process  the  heysord 
indexed  fields. 

one  SOB/TAB  card  aust  be  subaitted  for  each  subroutine 
referred  to  by  the  IBDBI  stateaeats.  A subroutine  or  table 
nay  be  defined  for  one  function  only  in  an  Index 
Specification  run,  and  each  unique  subroutine  or  table  wane 
nay  be  subaitted  only  once  per  run. 

All  SUB/TAB  stateaeats  aust  appear  first  in  the  input 
streaa,  before  the  IBDBX  stateaeats. 

The  SOB/TAB  stateaeat  is  free-foraat.  The  operands  aust 
be  in  order,  each  separated  froa  the  others  by  at  least  oae 
Hank.  A period  is  required  after  the  last  entry  to  signify 
the  end  of  the  statenent. 


a.  Statenent  Identifier 

SOB  or  SOBBOOTIHE  - subroutine  statenent 
TAB  or  TABLE  - table  statenent 
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b.  subnaae  - subroutine  or  table  naae 

c.  Function  Identifier 

For  Keyword  Indexes: 

STOP  * subnaae  to  be  used  with  Stop  (ford  Table 

Diet  (or  DICTIORABI)  - subnaae  to  be  used  with 

Dictionary 

SCAN  - subnaae  is  a user  scan  routine 

This  is  the  last  operand  for  a Keyword 
SOB/TAB  stateaeat. 

For  Secondary  Indexes: 

ANALYZE  - specifies  conversion  of  data  to 
index  foraat 

CONTEST  - specifies  analysis  of  index  usage 

The  following  operands  are  reguired  for  the  CONVERT 
function. 

d.  nnn  One-,  2-,  or  3-digit  field  specifying  the 

length  in  bytes  of  the  input  to  the  table  or 
subroutine. 

e.  nnn  One-  or  2-digit  field  specifying  the  length  in 

bytes  of  the  output  produced  by  the  table  or 
subroutine  (aaxiaua  is  30). 

f.  ALPHA 

BINABI  Node  of  data  output  by  the  subroutine  or 

COORD  table 

DECIHAL 

Exanple  of  a CONVERT  statement: 

SUB  convsub  CONVBRT  17  2 ALPHA. 
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Example  of  an  ANALYZE  stateaent: 

SUB  analsub  ANALYZE. 
Example  of  a DICTIONARY  stateaeat: 
TAB  DICTNANE  DICT. 


11.1.2  INDEX  Stateaent 

An  INDEX  statement  aust  be  provided  for  each  data  file 
field  to  be  designated  as  an  index  and  for  each  index  field 
to  be  deleted.  The  delete  operation  does  not  reaove  the 
f.eld  froa  the  file;  it  aerely  eliainates  the  option  of 
indexing  the  file  on  the  contents  of  that  field. 


Like  the  SOB/TAB  statement,  the  INDEX  statenent  is  free* 
foraat.  Unless  otherwise  indicated  the  operands  are  order* 
dependent.  Each  nust  be  separated  froa  the  others  by  at 
least  one  blank.  A period  is  repaired  after  the  last 
operand  to  signify  the  end  of  the  stateaent. 


INDEX  fieldnaae  [ADD 

DELETE 


convsnbnaae  aaalysubaaae 


keyword  stopnaae  dictnaae  scaaaaae 


TEXT 

SEPARATE 

DEOP 

■STAIN 


a.  Stateaeat  Identifier  * INDEX 

**•  fieldnaae  FPT  aaae  of  field  or  groap  to 

be  indexed 

c.  Action  Indicator 

ADD  • field  is  to  be  added  as  an  index.  This 
is  the  default  value.  However,  it  is 
required.  If  a conversion  aad/or 
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analyzer  subroutine/table,  or  KEIUORD 
indexing  is  defined. 

DELETE*  field  is  to  be  reaoved  as  an  index,  the 
data  field  itself  is  not  affected. 

This  is  the  last  operand  required  for 
delete  action. 


The  following  two  optional  operands  are  used  only  with 
secondary  indexes. 

d.  convsubnaae  Naae  of  the  table  or 

subroutine  to  convert 
data  data  fron  datafile 
foraat  to  index  data  set 
foraat. 

e.  analysubnaae  Naae  of  subroutine  to  be 

used  to  analyze  a 
FUNCTION  operator 

paraaeter  list  and 
deteraine  index  usage. 

NOTE:  If  both  conversion  and  analyzer  subroutines  are 

specified,  the  conversion  subroutine  aust  be 
specified  first.  If  only  one  is  specified,  its 
function  will  be  deterained  fron  the  paraaeters  on 
the  SUB/TAB  stateaent.  An  analyzer  subroutine  or 
table  say  not  be  used  as  a conversion  routine,  and 
a conversion  subroutine  or  table  may  not  be  used  as 
an  analyzer  routine  in  the  sane  Index  Specification 
run. 

The  renaining  operands  are  used  only  when  defining 
keyword  indexed  fields: 


f.  KEYWORD 

g.  stopnane 


Required  to  differentiate 
between  the  two  types  of 
indexed  fields 

naae  of  the  Stopword 
Table  (optional) 
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h.  diet BUBO 

i.  SCBBBBBO 


j.  Hyphen  Option 
TEXT 


SEPARATE 


DBOP 


RETAIN 


naae  of  the  Dictionary 
(optioaal) 

Base  of  user  scan  routine 
(optional) 


■o  text  editing.  Hyphens 
reaain  as  they  appear  in 
the  text.  The  default  is 
TEXT. 

Hyphens  are  aluays 
treated  as  word 
separators  and  are 
replaced  with  blanks. 
Hypenated  words  are 
treated  as  two  or  aore 
separate  words. 

Hyphens  are  always 
dropped.  If  a hyphen  is 
preceded  by  a text 
character  and  followed  by 
a text  character  or  one 
or  aore  blanks  and  a text 
character,  the  hyphenated 
text  is  connected  to  the 
following  text  string 
without  the  hyphen. 

The  opposite  of  DBOP. 
Hyphens  are  always 
retained.  As  with  DBOP, 
hyphenated  text  is 
connected  with  following 
text,  but  thy  hyphen  is 
retained  as  an  enbedded 
character  of  the  whole 
word. 
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Any  combination  of  stopname,  diet name,  scanname  and  hyphen 
option  nay  be  specified  in  any  order. 

Example  of  an  Add  Index  Action: 

INDEX  HEQPT  ADD  CONSOB. 

Example  of  a Delete  Index  Action: 

INDEX  CNTRY  DELETE. 

Example  of  an  Add  Keyword  Index  Action: 

INDEX  ANAHE  ADD  KEXRORD  RETAIN 
SCANNER  STOPPER  KEYVDS. 


11.2  UTNDXSPC  Output 

(JTNDXSPC  builds  and  inserts  Index  Descriptor  Records 
into  the  data  file  for  indexes  added  and  deletes  Index 
Descriptor  Records  for  indexes  deleted.  It  then  calls  Index 
Maintenance  to  either  generate  or  update  the  Index  Data  Set. 
(JTNDXSPC  also  lists  a summary  of  actions  performed  plus  any 
error  conditions  encountered. 


11.3  UTNDXSPC  Job  Setup 

The  following  JCL  examples  can  be  used  to  invoke  the 
cataloged  procedure  XSP  which  will  either  generate  or  update 
a disk-resident  Index  Data  Set  based  on  the  ISAH,  SAH  or 
V3AH  data  file. 

The  first  example  illustrates  a situation  in  which  an 
index  data  set  is  to  be  regenerated.  The  uncatalogued  SAN 
data  file,  RTFILE,  resides  on  a 9-  track  tape  with  standard 
labels  and  system  default  density.  It  contains  Index 
Descriptor  records  in  the  FFT  from  previous  runs.  The  new 
Index  data  set  must  have  the  same  name  as  the  data  file  (the 
system  will  suffix  an  X).  The  new  index  will  have  the 
default  blocksize  of  560  and  default  number  of  blocks  of 
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200.  Blocksize  ■ ust  be  between  560  and  1020  bytes  and  at 
least  50  blocks  nest  be  allocated. 

//SAMPLE 1 JOB  (standard  paraaeters) 

//STEP1  EXEC  XSP,Sia*flYFILE,YSAH**SBB*flTTAPEa, 

//  IRDEI=HYFILE, XYOL* •SER*HYDISk* ,XDISP*HE«, 

//  SAHOUT=#PARH*GBH 

//SYSIM  DD  * 

(Index  Specification  statenents) 

/* 

note  sahout=#  is  required  for  SAB  runs.  PARH*GER  is  required 

when  generating  a new  Index  Data  Set  and  Index  Descriptor 
records  exist  in  the  data  file  FFT. 

In  the  following  exaaple,  index  specifications  on  the 
catalogued  index  data  set  HYFILBX  and  the  ISAM  data  file 
BY  FILE  will  be  updated: 

//SAMPLE 2 JOB  (standard  paraaeters) 

//  EXEC  XSP,ISAB*HYFILE,IIHDBX*HYFILB 

// SYSIN  DD  * 

(Index  Specification  statenents) 

/* 


The  following  will  update  the  index  specification  for 
the  VSAM  file,  VSAH.NYFILE,  catalogued  on  RIPS. CAT: 

//sample 3 JOB  (standard  paraaeters) 

//  EXEC  XSP, ISAM* ' VSAH.HYFILB', XIRDEX*HYFILE , 

//  VSC AT*  * HI  PS. CAT* 

//UTXSP.NEMFILB  DD  AMP*' AHORG* 

//SYSIN  DD  * 

(Index  Specification  statenents) 

/• 
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Section  12 

INDEX  TR1NSFER  (UTNDITFR) 


An  Index  Data  Set  nay  reside  on  a direct-access  device 
or  on  tape,  but  only  the  disk-resident  aediua  can  be  used  by 
any  NIPS  coaponent.  Index  Transfer  (OTNDXTPR)  peraits  the 
user  to  transfer  the  entire  data  set,  froa  one  resident 
aedium  to  the  other. 

The  priaary  use  of  OTNDXTPR  is  to  reorganize  the  disk- 
resident  indexes.  Initially,  a disk-resident  Index  Data  Set 
is  packed  with  index  inforaation.  As  the  indexes  are 
maintained,  gaps  or  unused  areas  aay  occur  in  the  data  set 
as  records  are  deleted  and  others  are  added.  By  using 
UTNDXTPR , the  user  can  transfer  the  disk-resident  data  (only 
the  valid  inforaation  is  transferred)  to  tape,  and  again 
froa  tape  back  to  disk.  This  operation  condenses  the  data 
set.  The  tape  so  created  aay  be  retained  as  a backup. 

In  the  disk  to  tape  node  of  operation,  a statistical 
printout  of  unigue  values  (for  secondary  indexed  fields)  and 
keywords  (for  keyword  indexed  fields)  and  their  occurrences 
are  optionally  developed.  Binary  valaes  will  be  converted 
to  decinal  for  ease  of  reading.  However,  any  dictionary 
fields  using  conversion  subroutines  or  keyword  fields  having 
synonyns  in  the  dictionary,  will  be  printed  in  the  converted 
fora,  just  as  they  appear  in  the  Index  Data  Set. 


12.1  UTNDXTPR  Input 

Two  cataloged  procedures  are  available  for  invoking  the 
UTNDXTPR  utility.  XTRDISK  will  transfer  a disk-resident 
Index  Data  Set  to  a sequential  access  nediun,  while  XTRTAPE 
will  reconstruct  an  Index  Data  Set  froa  a previously 
unloaded  tape  version  of  the  disk  data  set. 
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12.2  UTNDXTFR  Output 

UTNDXTFR  produces  an  Index  Data  Set  on  the  residence 
mediun  indicated. 


12.3  UTNDXTFR  Job  Setup 

The  following  statements  illustrate  the  deck  setup  used 
to  unload  the  TESTER!  Index  data  set  fron  a 2314  disk  pack 
to  a 9-track  unlabeled  tape. 

//JOBNAME  JOB  (standard  paraaeters) 

//STEPNANE  EXEC  XTRDIS  K,XPNAHE=TESTERX, 

//  XF?OL=  *SEH=HTPACK*  , XTMAHE-INXS AH , 

//  XTVOL* •SBR^HYTAPE* 

The  following  exaaple  illustrates  the  deck  setup  to  be 
used  for  a VSAN  file,  YSAH. HTFILE , cataloged  on  NIPS. CAT: 


//JOBNAHE  JOB  (standard  parameters) 

//STEPNANE  EXEC  XTRDISK,XFNAHE=*VSAH.HTFILE*, 

//  XFVOL=  * SE8=HTPACK* , XTNAHE=' ?SAH. IHXSAH * , 

//  XTTOL=*  SER*HTTAPE* , FSCAT* • NIPS. CAT* 

//XTR. DATAFILE  DD  A HP=*  AHORG * 


The  following  example  illustrates  the  deck  setup  to  be 
used  to  reconstruct  a disk  resident  index  data  set  fron  a 
previously  unloaded  version  of  index  data  set. 


//JOBNAHE 

//STEPNANE 

// 

// 


JOB  (standard  parameters) 

EXEC  XTRTAPE,XTNAHB=TBSTEHX, 
XTVOL= ' SER*HIPACK • , 
XFNANE=INXSAH,XFVOL»*SER*HTTAPE* 


60 


Utility  Support  (OT) 
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Section  13 
UTFLDSCN 


UTFLDSCN  scans  the  HIPS  components  source  statements  and 
provides  the  user  with  the  count  of  data  fields  referenced 
in  the  source  statements.  This  utility  is  useful  in  helping 
the  analyst  to  determine  the  activity  of  his  data  fields. 
This  will  assist  the  user  in  determining  which  fields  are 
candidates  for  index  fields  in  the  Secondary  Indexing 
capability. 

The  utility  processes  source  statements  pertaining  to  a 
single  file  in  one  execution.  Multifile  RITs  and  multifile 
queries  will  be  accepted  as  input;  however,  only  the  data 
fields  of  the  input  data  file  will  be  processed.  All  other 
files  will  be  iqnored.  In  order  to  completely  process 
multi-file  RITs  and  multifile  queries,  it  would  be  necessary 
to  include  the  source  statements  in  an  execution  for  each 
file  referenced. 

UTFLDSCN  outputs  a listing  of  the  source  input 
statements  followed  by  a listing  of  the  count  of  references 
for  the  data  fields  and  a summary  listing  of  data  field 
reference  count  for  each  batch  component.  A transaction 
record  will  also  be  output  for  each  data  field  referenced  in 
a single  source  input  statement. 


13.1  UTFLDSCN  Input 

Input  to  the  utility  consists  of  a NIPS  data  file  in 
SAM,  ISAM  or  VSAN  format,  a control  card,  and  the  source 
input  statements  and/or  members  of  a partitioned  data  set. 

The  format  of  the  input  control  card  is  as  follows: 

./  SOURCE  CONP-XXXX, NAHB=SNAMB,MEHBER*MNAME 

where  ./  must  be  in  columns  1 and  2 followed  by  one  or 
blanks. 
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cohp*XXXX  whore  XXXX  oay  be  PH,  HASP,  OP,  or  QUIP 
to  identify  the  component. 

HA RE-SNARE  where  SNARE  is  the  naee  of  the  source 

statement.  If  the  source  is  a logic  sta tenant, 
the  nase  nust  be  the  report  naae  and  logic 
stateaent  nanes  enclosed  in  quotes.  If  the 
report  naae  is  less  than  seven  characters,  it  must 
be  padded  wit 2 blanks  to  seven  characters. 

HEHBEB=flNAHE  where  HNAHE  is  the  aeaber  naae  of  the 
source  stateaent  on  a partitioned  data  set. 

If  this  operand  is  used,  a partitioned  data  set 
aust  be  included  in  the  job  streaa.  If  this 
operand  is  oaitted,  the  source  statenents  aust 
follow  the  control  card  in  the  input  streaa. 


1 ). 2 UTPLDSCN  Output 


The  outputs  froa  OTFLDSCR  are  as  follows: 


Source  Listing  - The  source  input  records  in  input 

order. 


Field  Listing  - This  output  consists  of  a header 

for  each  source  deck  indicating  file 
naae,  coaponent  naae,  source  naae,  and 
aeaber  naae,  if  any.  The  body  of  the 
listing  consists  of  only  those 
fields  referenced  and  the  count  of 
references.  This  sill  follow  the 
source  listing  for  each  source  nodule. 
After  all  source  aodules  have  beea 
processed,  a suaaary  listing  sill  be 
provided  containing  the  count  of  the 
field  references  par  coaponent. 


Transaction  - The  transaction  data  set  vill  be  50 
Data  Set  characters  long  with  an  • S*  in  coluaa 

one  to  be  used  as  a logic  stateaeat 
naae.  The  foraat  is  as  follows: 
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Coluan  1 
2-8 
9-12 
13-25 
26-33 
34-36 
37-42 
43-48 
49-50 


CHARACTER  *S* 

FILE  BABB 

COHPOBEBT  BABB 

SOOBCB  BOOOLB  BABE 

FIBLD  BABE 

SBT  BOBBER,  DBCIBAL 

COOBT  OF  REFBBBBCES,  DPCIBAL 

DATS  - HBDDTT 

OB  OS  ED 


Paraaeters  aay  be  entered  in  the  PARfl  field  on  the  BXBC 
card  to  suppress  output.  They  are  as  follows: 

BS  - Suppress  printing  of  source  input 

BL  - Suppress  field  and  suaaary  listing 

BT  - Suppress  transaction  output. 


1J.3  Job  Setup 

The  utility  is  executed  by  a procedure,  XOTFSCAB.  If 
the  input  stateaents  are  aeabers  of  a partitioned  data  set, 
the  data  set  aust  be  included  in  the  job  streaa.  The 
following  stateaents  illustrate  the  job  setup  used  to 
execute  the  XOTFSCAB  procedure  against  the  ISAA  data  file 
TEST360: 

//  EXEC  XOTFSCAB, ISAB=TEST360,LIB*TEST360 
//SXSIM  DO  ♦ 

./  SOURCE  C0BP=FB, BABB*' TBSTO  A* ,HEBBEB=TEST A 
./  SOOBCB  COBP=R ASP, BABE*TESTO 1 
BASP  Query  Stateaents 


m 

./  SOURCE  COBP*OP, HABB*TESTFFF 
OP  BIT  Statements 

e 

./  SOOBCB  COHPaQOIP, RABE*QTBST, HBBBBB*QTESTA 
/* 
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Tho  £ol loving  JCl  could  bo  usod  to  esecute  tho  XUTFSCAN 
procedure  against  the  Till  dots  file  VSAH*TBST3dO: 

//  EXEC  XUTPSCIE.ISiB-^fSdB.TISTJdO^.lIE-flSfJdO, 

//  VSCAT«»EIPS.CIT« 

//UTFLDSCN • DATAFILE  DD  A«P-»AEOEC* 

//UT  PL  DSC  A.  STS  I ■ DD  • 


(field  scan  control  stntenonts) 

✓* 
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Section  14 
0TIDXKAI 


UTADXKAM  provides  the  user  with  the  capability  to 
analyze  the  words  in  fields  for  which  keyword  indexing  is  to 
be  specified.  The  resnlts  of  the  analysis  can  be  used  to 
deteraine  the  contents  of  stop  word  tables  and  dictionaries 
that  are  to  be  associated  with  those  fields.  If  the  systea 
scan  subroutine  does  not  recover  words  as  the  user  desires, 
a user- written  scan  subroutine  can  be  used  with  this 
utility.  All  the  words  contained  in  a data  base  field  can 
be  displayed,  or  those  words  which  are  irrelevant  (noise 
words)  can  be  selected  and  coapared  to  the  words  in  the 
systea  stop  word  table.  If  that  table  is  not  adeguate,  the 
Dictionary  Maintenance  utility  can  be  used  to  build  a user 
stop  word  table.  Then  this  utility  is  able  to  list  all 
relevant  (nonstop)  words  which  can  be  used  to  deteraine 
dictionary  requireaents.  If  a dictionary  is  not  eaployed, 
the  words  not  in  the  stop  word  table  will  all  appear  as 
keyword  entries  in  the  index  data  set.  Through  dictionary 
application,  synonoaous  words  and  words  with  varying 
suffixes  can  be  collected  under  one  Index  Data  Set  entry, 
and  the  synoaya  or  suffixed  fora  can  still  be  used  in  a 
query  statenent.  The  Dictionary  Maintenance  utility  can  be 
used  to  build  a dictionary  so  that  this  utility  can  produce 
a list  of  the  words  which  will  becoae  Index  Data  Set  entries 
together  with  the  keywords  (including  synonyas  and  suffixed 
words)  associated  with  then  which  can  be  used  as  query 
argunents. 

UTMDXKAN  processes  either  a SAM,  an  ISAM  or  a VSAH  data 
file.  The  fields  that  are  to  be  processed  are  specified  by 
control  statenents.  For  each  field  specified,  the  utility 
obtains  froa  the  control  statenent  or  fron  the  file  itself 
the  nanes  of  the  scan  subroutine,  stop  word  table  and 
dictionary  required  to  process  that  field.  It  scans  all 
values  in  the  data  base  (unless  the  nanber  of  records  to  be 
processed  has  been  United  by  the  user)  , optionally  aatches 
the  recovered  words  to  a stop  word  table,  then  optionally 
aatches  the  renaining  words  to  a dictionary.  The  actual 
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functions  performed  are  controlled  by  accepting  naaes  to  FFT 
entry  specifications  or  by  specifying  BYPASS.  Override 
naaes  or  BYPASS  east  be  specified  for  all  functions  if  the 
FPT  entry  does  not  indicate  keyword  indexing. 

UTMDXKAR  displays  word  lists  with  record  frequency 
counts  or,  optionally,  record  identifications  for  each  field 
processed  or  for  all  fields  as  a group.  Frequency  count 
reflects  the  nuaber  of  RIPS  records  in  which  a word  appears 
at  least  once. 


14.1  Input 

UTNDXKAN  accepts  PILE  and  FIELD  control  stateaents.  The 
FILE  stateaent  is  optional.  At  least  one  field  statenent  is 
required,  control  stateaents  are  coded  on  cards  or  as  card 
iaages  and  are  contained  in  coluans  1 through  71.  Each 
stateaent  nust  begin  in  a new  record  with  the  stateaent 
identifier  FILS*  or  FIELD*  in  colaan  1 of  that  record.  The 
file  or  field  naae  shall  iaaediately  follow  the  stateaent 
identifier.  A stateaent  that  exceeds  71  characters  can  be 
continued  on  one  or  sore  additional  cards  in  coluans  1 
through  71.  A aonblaak  character  aust  be  placed  on  coluan 
7?  to  indicate  continuation.  A control  stateaent  can  be 
interrupted  after  any  coaaa  or  blank.  lords  aay  not  be 
split  between  records.  Coluan  72  of  the  last  or  only  record 
of  each  control  stateaent  aust  be  blank.  Coluans  73*80  of 
all  records  ace  ignored. 

A control  stateaent  operand  is  nade  up  of  two  or  sore 
keyword  paraaeters.  Each  operand  aust  be  preceded  and 
followed  by  one  or  aore  blanks  or  coaaas  unless  an  operand 
teramates  in  coluan  71,  in  which  case  a continuation 
character  (ia  coluan  72)  aay  follow  the  operand.  If 
•ultiple  values  are  specified  for  an  operand,  at  least  one 
blank  or  coaaa  aust  separate  each  value  and  the  group  of 
values  aust  be  enclosed  in  parentheses.  The  operands  can  be 
coded  in  any  order.  Ro  extra  coaaas  are  required  to 
indicate  on it ted  operands. 
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14.1.1  PILE  Statement 

I 

The  PILE  stateaent  eay  be  oaitted.  It  applies  to  file 
processing  and  affects  all  the  fields  to  be  processed.  If 
used,  it  eay  appear  only  once  and  aust  be  the  first 
stateaent.  Its  operands  allow  control  of  file  access  and 
output  aerging. 

The  foraat  of  the  PILE  stateaent  is  as  follows: 

FILE=f ilenaae 

"stop 

HERGEsYES  bypass-  monkey 

KEYWORD 
SYMOMYH 
_SOPFIIES 

SKIP=nnnn  STOPAFT=nnnnn 

a.  Stateaent  Identifier 

PILE-filenaae  - aust  be  coded  in  coluan  1; 
specifies  v.he  naae  of  the  file. 

b.  MERGE=YES 

Specifies  that  the  word  lists  froa  all  fields 
should  be  aerged  into  one  group  of  lists  that 
reflects  the  entire  file. 

c.  BYPASS=  (optionl, option2, .. .) 

Defines  the  word  lists  to  be  suppressed  for 
all  fields  and  overrides  the  FIELD  stateaent 
BYPASS  operand.  Only  valid  if  MEBGE*YES  is 
specified.  The  display  list  identified  by  the 
following  terns  are  oaitted  froa  the  output 
for  all  fields: 

STOP  stop-word  table  Batches 

MONKEY  stop-word  table  and  dictionary 
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non  Batches 

KEYWORD  dictionary  Batches  iacluding 

synonyn  sublists 

STROM  YH  keyword  sublists 

SUFFIXES  dictionary  non  Batches  which  are 

coaposed  of  keywords  with  valid 
suffixes;  the  keywords  appear 
in  the  keyword  list. 

d.  SKIP=nnnnn 

A nuaber  between  1-  32,767  of  RIPS  logical 

records  to  skip  before  processing  any  fields. 

e.  STOPAFT=nnnnn 

A nuaber  between  1*  32,767  which  specifies  the 
aaxiaaa  nuaber  of  MIPS  logical  records  to 
process  before  stopping. 


14.1.2  FIELD  Stateaent 

The  FIELD  stateaent  identifies  a field  to  be  analyzed. 
* least  one  FIELD  stateaent  is  reguired  and  up  to  50  are 

allowed. 

The  foraat  of  the  FIELD  stateaent  is  as  follows: 


?lELD=fieldnaae 

SCAN=naae 


DICT- 


HYPEH- 


un 

DROP 

RETAIR 

SEPARATE 
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BYPASS* 


STOP 

BOBKBY 

KEYWORD 

SYNONYM 

SUFFIXES 


RBCID 


a,  Statement  Identifier 

FIELD* field naae  - a ust  be  coded  in  coluan  1. 
Specifies  the  naae  of  the  field  or  variable 
set  to  be  analyzed. 


b. 


c. 


d. 


SCAR*naae 

Identifies  the  scan  subroutine  to  be  used 
instead  of  the  FFT  scan  subroutine  or  the 
systea  scan  subroutine. 


Overrides  the  FFT  stop- word  table 
specification  or  specifies  BYPASS  to  cause  the 
stop- word  table  Batch  function  to  be  oaitted 
for  the  field  in  which  case  all  recovered 
words  are  nonstop  words.  The  default  is 
BYPASS. 

DICT*  |~BTPASsj 


Overrides  the  FFT  dictionary  specifications  or 
specifies  BYPASS  to  cause  the  dictionary  aatch 
function  to  be  oaitted  for  this  field  in  which 
case  all  nonstop  words  are  keywords.  The 
default  is  BYPASS. 


e. 


HYPEN* 


TBIT 

DROP 

RETAIN 

SEPARATE 
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Overrides  the  FFT  option  specification. 
Default  value  is  TEXT.  Discussion  of  HYPBH 
options  aay  be  found  in  section  11.1.2  of  this 
volune. 

f.  BY  P A SS= (option  1 , opt ion 2. . • ) 

Mot  applicable  if  BYPASS  was  specified  on  a 
FILE  statement.  It  defines  the  word  lists  to 
be  suppressed  for  the  field.  The  display 
lists  identified  by  the  following  terns  are 
oaitted  froa  the  output  for  the  field. 

STOP  stop-word  table  Batches 

MONKEY  stop-word  table  and  dictionary 

non  watches 

KEYWORD  dictionary  Batches  including  synonya 
sublists 

SYMOMYH  Keyword  sublists 

SUFFIXES  dictionary  non  Batches  which  are 
coaposed  of  keywords  with  valid 
suffixes;  the  keywords  appear  in 
the  keyword  list. 

g.  BECID- 


Specifies  that  record  identification  are  to  be 
shown  in  the  word  lists  instead  of  frequency 
counts.  The  default  is  MO. 


It. 2 Output 

UTNDXKAN  displays  one  list  of  words  with  either 
frequency  counts  or  aajor  record  identifications  for  each 
fj?ld  processed  or  for  all  fields  as  one  group  if  the  serge 
option  is  specified.  A 2-character  code  associated  with 
ench  word  identifies  its  type.  Words  froa  types  for  which 
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bypass  is  specified  are  ositted  from  the  list.  If  a 
dictionary  was  specified  and  a data  word  natched  a convert 
synonya  or  was  suffixed,  the  dictionary  word  which  will  be 
substituted  for  the  data  word  is  inserted  after  the  data 
word  at  an  offset. 


14.3  Job  Setup 

The  following  JCL  stateaents  illustrate  the  deck  setup 
used  to  invoke  the  XKA  cataloged  procedure  for  a cataloged 


ISAM  file  and 

a cataloged  user  library: 

//  EXEC  XKA,IS AM«f ilenaae, LIB*libnaae 
//XKA.SYSIH  DD  * 

(user-supplied  control  stateaents) 

/* 

wiiere 

filenaae 

- naae  of  the  HIPS  ISAM  data 

file 

libnaae 

- naae  of  library  containing  user  scan 

subroutines,  stop  word  tables  and 
dictionaries. 

The  following  JCL  stateaents  illustrate  the  deck  setup 
u;;ed  to  invoke  the  XKA  cataloged  procedure  for  an 
uncataloged  SAM  file  and  an  uncataloged  user  library: 

//  EXEC  XKA,SAH=filenaae, VSAM*'SER=aaaaaa • , 

//  LIB=libnaae, VLIB= • SEH=bbbbbb* 

//XKA.SYSIH  DD  ♦ 

(user-  supplied  control  stateaents) 

/* 

where 

filenaae  - naae  of  the  HIPS  SAM  data  file 

aaaaaa  - serial  nuaber  of  the  SAM  data  file 


71 


Utility  Support  (UT| 


libnaae 


bbbbbb 


nane  of  the  library  coattlaiag  user 
seas  sub routines,  stop  vord  tables,  and 
dictionaries 

serial  aunber  of  the  user  library* 


The  following  JCL  statesents  illustrate  the  dock 
satup  used  to  invoke  the  XKA  cataloged  procedure  for 
a ¥SAH  data  file  cataloged  on  a UPS.  CAT; 

//  EXEC  XKA,VSCATs'HIPS.CAT* , 

//  ISAfl=filenane, LI libnaae 
//XKA. DATAFILE  DD  AHP=* AHORC* 

//XKA.STSII  DD  * 

(user-supplied  control  stntesents) 

/* 
w tere: 


filenane  - nane  of  MIPS  TSAB  data  file 

libnaue  - nane  of  the  library  containing 

user  scan  subroutines,  stop  word 
tables,  and  dictionaries. 
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Section  15 

DICTIOHABI  RAI NTEHANCE  (UTHDXKHD) 


UTMDXKHO  creates,  updates,  and  displays  stop- word  tables 
and  dictionaries.  During  one  execution  it  processes  any 
nunber  of  tables  provided  all  tables  are  stored  in  the  sane 
library.  It  accepts  as  input  table  statements  which  define 
functions  to  be  perforaed  and  value  statements  which  provide 
data  for  create  and  update  functions.  Each  table  statement 
defines  one  of  the  following  functions. 

- add  stop  words 

- delete  stop  words  (update) 

- add  keywords 

- add  suffixes 

- add  synonyms 


- delete  keywords  (update) 

- delete  suffixes  (update) 

- delete  synonyms  (update) 

- display  stop  word  table 

- display  dictionary 

In  addition,  a table  statement  may  include  parameters 
which  define  a table  page  size  (create),  dictionary  display 
options,  and  value  statement  display  and  sequence  check 
options.  Since  a table  statement  defines  only  one  function, 
more  than  one  table  statement  with  its  associated  value 
statements  will  probably  be  required  to  create  a dictionary 
or  to  update  any  table.  For  ease  of  reference,  a table 
statement  and  its  value  statements  will  be  called 
collectively  a function  statement. 
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Table  Creation 

Onlf  one  function  statenent,  ADD*STOPHOBDS,  is  reqaired 
(or  pernitted)  to  create  a stop  word  table,  false  statenent 
uordr  should  be  those  words  which  appear  un;  tines  (high 
frequency)  or  which  the  user  will  newer  nse  as  search  terns. 
If  the  anount  of  data  is  snail,  a stop  word  table  will 
probably  not  be  reqaired.  If  the  anount  of  data  is  wary 
large,  the  user  would  benefit  by  executing  the  Keyword 
Analysis  utility  to  obtain  word  frequency  counts.  fords 
which  appear  in  nore  than  25  percent  of  the  data  file 
records  are  good  stop  word  table  candidates. 

Three  function  statenents  nay  be  used  to  create  a 
dictionary  — add  keywords,  add  suffixes,  and  add  synonyns. 
However,  all  three  statenents  nay  be  used  to  define 
dictioaary  words  with  suffix  specifications.  If  no  synonyns 
are  to  be  defined,  only  the  add  keywords  statenent.  need  be 
used;  if  only  synonyns  are  to  be  defined,  only  the  add 
synonya  statenent  need  be  used.  On  the  other  hand,  all 
three  statenents  nay  be  used  to  define  the  sane  word  as  a 
keyword  (add  keywords)  whose  ending  changes  when  it  is 
suffixed  (add  suffixes)  and  that  is  synononous  with  another 
word  (add  synonyns).  If  nore  than  one  function  statenent  is 
used,  the  statenents  nay  appear  in  any  sequence  in  the  input 
streaa.  in  fact,  function  statenents  and  display  statenents 
froa  any  aunber  of  tables  nay  be  interaixed.  The  only 
sequence  restriction  occurs  when  the  user  chooses  to  have 
utmdikhd  sequence  check  the  value  statenents  in  a function 
statenent.  UTIDXKHD  processes  the  input  in  phases:  it 
processes  each  function  statenent  as  an  independent  unit, 
then  it  processes  each  unique  table  word  froa  all  function 
statenents. 

Dictionary  words  should  noraally  be  those  words  which 
change  their  fora  when  snffixed  or  which  are  to  be  grouped 
under  one  tern  in  the  Index  Data  Set.  However,  low 
frequence  words  in  a very  large  data  base  night  also  be 
included.  The  decision  to  exclude  words  by  using  a stop 
word  table  or  to  inclade  then  by  nsiag  a dictioaary  is 
arbitrary.  Using  a stop  word  table  should  increase  run 
tine.  However,  when  both  tables  are  ased,  both  aust  be 
changed  to  inclade  a word  which  is  a stop  word. 
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Table  Update 

Add  stop-word  and  delete  stop-word  statements  are  used 
to  update  a stop-word  table.  All  other  function  statements 
are  used  to  update  a dictonary.  The  difference  between 
create  and  update  is  that  during  update  all  input  words  are 
matched  against  existing  tables.  Rote  that  an  existing 
table  may  be  created;  in  create  mode,  UTNDXKHD  does  not  test 
tor  the  existence  of  a table  — it  creates  a new  table  from 
input  data  that  replaces  the  existing  table. 

UTNDXKHD  does  not  include  a delete-table  function.  Use 
the  OS  utility  IEHPHOGfl  to  scratch  each  page  (member). 

Dictionary  delete  function  statements  are  more  specific 
than  add  statements.  A delete  keyword  statement  removes 
tnat  word  from  a table;  it  also  removes  all  changed-form 
suffix  entries  and  synonym  entries  associated  with  the  word. 
A delete  suffixes  statement  removes  only  changed-form  suffix 
entires;  the  root  word  and  synonym  entries  remain  unchanged. 
A delete  synonym  statement  removes  only  synonym  entries. 
Another  difference  between  add  and  delete  statements  is  that 
add  synonym  words  must  be  grouped  in  parentheses  to  show 
synonomous  relationships;  delete  synonym  words  are 
independent  and  require  no  parentheses. 


15. 1 UTNDXKHD  Input 

UTNDXKHD  accepts  table  and  value  statements  from  the 
SYSIN  device.  Formats  conform  to  general  NIPS 
specifications.  statement  entries  are  punched  in  free 
fornat  in  positions  1-71.  Position  72  is  used  for  table 
statement  continuation  (value  statements  are  not  continued). 
Positions  73-80  of  value  statements  will  be  optionally 
sequence  checked  within  each  function.  Blanks,  commas,  and 
parentheses  are  used  as  entry  delimiters  and  nay  not  be  part 
of  an  entry;  the  equals  symbol  is  used  to  identify  table 
entries  and  nay  not  be  used  for  any  other  purpose.  All 
other  characters  are  assumed  to  be  part  of  entry  terms; 
literals  are  not  recognized  as  such  because  they  are 
irrelevant  table  entries. 
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Table  Stateaeats 

Table  stateaaet  eatries  are  coapoaed  of  keywords  aad 
operands  separated  by  an  egwals  syabol.  lith  the  exception 
of  the  display  keyword,  all  operaads  are  single  ter  as.  If 
two  teras  are  ased  ia  the  display  keyword  operand  they  east 
be  enclosed  in  parentheses;  otherwise  no  special  notation  is 
reqaired  with  any  operand. 

The  table  type  keyword  (STOP0O1D,  DICTIOBABI)  identifies 
the  beginning  of  a table  stateaeat.  It  aast  be  panched 
beginning  in  cal  nan  1 of  the  inpat  record.  Ill  other 
keywords  and  operaads  nay  be  panched  ia  any  position  in 
co loans  1-71.  it  is  peraissible  to  panch  a keyword  in  one 
record,  an  egaals  syabol  in  a second  record,  aad  the  operand 
in  a third  record,  lo  keyword  or  operand  any  be  split 
between  records,  boaewer.  kay  naaber  of  blanks  aad  coaaas 
nay  appear  between  terns  and  aroand  the  egaals  syabol  (aad 
a parentheses  if  any  are  reqaired) . hll  records  except  the 
last  (or  only)  record  that  contain  table  stateaeat  teras 
east  include  a aonblaak  peach  ia  position  72  to  indicate 
that  the  record  is  not  the  last  (or  only)  one  for  the 
stateaeat. 

The  table  type  keyword  and  the  node  keyword  (CHEATS, 
update,  DISPLAY)  are  reqaired  in  all  table  stateseats.  The 
operation  keyword  (ADD,  DELETE)  is  r eg aired  in  all  create 
and  apdate  aode  table  stateaeats. 

All  other  keywords  are  optional.  la  create  aode,  the 
user  can  specify  a aaxiaaa  table  page  size  (PAGE) . If  he 
does  not,  a IK  default  size  will  be  ased.  Bote  that  if 
in pat  data  for  a table  does  not  coapletely  fill  one  page, 
the  actual  page  size  will  be  egaal  to  the  space  ased,  not 
the  nazinaa  size.  However,  the  aaxiaaa  size  will  be  carried 
in  the  table  directory  and  will  be  considered  each  tine  the 
table  is  apdated.  Ia  create  aad  apdate  node  stateaeats,  the 
user  can  request  that  all  valae  stateaeats  be  segaeace 
checked  (SEQCK)  and/or  displayed  for  diagnostic  re far ears 
(DIAGNOSTIC) . ia  display  sods  for  a dictionary,  tbs  aaer 
can  select  various  word  lists  (DISPLAY) . 
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& table  cannot  be  created  and  updated  in  the  sane  run. 
It  is  impossible  to  display  a table  before  it  is  updated  in 
the  sane  run  (stateaents  are  sorted  before  they  are 
processed) . Only  one  display  node  statement  may  be  present 
for  a stop  word  table;  any  number  may  be  present  for  a 
dictionary  provided  the  DISPLAT  keyword  operands  for  each 
are  unique. 


The  format  of  table  statement  entries  is  as  follows: 


STOPUOHD- 
DICT IONARY 


ADD= 
DELETE 


'I 

CREATE 

[ table  name 

MODE* 

UPDATE 

1 

DISPLAY 

— i 

STOPWOBDS 

KEYWORDS 

SUFFIXES 

SYNONYMS 


PAGE=nnk 


SEtfCK=N£_  PI AGNOSTIC* NOLIST  DISPLAY* 

YES  LIST 

a.  Statement  Identifier 

STOPBORD*  or  DICTIONARY*  must  be  first 

keyword,  must  begin  in  column  1. 

b.  table  name 

table  name  - must  be  less  than  8 characters  in 
length;  must  being  with  an  alphabetic 
character  and  can  not  end  with  zero. 

c.  NODE  identifier 

CRBATB,  UPDATE  or  DISPLAY 


FEIIORD 

SUFFIXES 

SYNONYMS 
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d. 


Operation  Keyword- word  type 


Bequired  for  CRBAT B/ UPDATE 
whether  keyword  table  is 
deleted;  and  the  type  of 
processed. 


JAD0S  1 

1dbletb=i 


operation 


STOPBOBDS 

KBTBOBDS 

SUFFIXES 

iSTIOITHS 


word  type 


nodes;  specifies 
being  added  or 
keyword  being 


e.  PAGE=nnk 


One  or  two  digits  in  range  of  1-32K;  default 
size  is  IK 


f.  SEQCK=HO 

TBS 

Specifies  whether  a sequence  check  is  to  be 
performed;  default  is  HO. 

g.  PI AG HO STIC =HOL 1ST 

LIST 

Specifies  whether  diagnostic  reference  listing 
is  to  be  printed;  default  is  HOLIST 

h.  DISPLAT=word  type 

Specifies  the  type  of  word  lists  that  are  to 
be  printed  in  the  DISPLAT  node;  the  default  is 
all  word  types. 
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/ 


KEYHOBDS 

SUFFIXES 

STHONTHS 


word  type 


If  two  teres  are  selected,  they  aust  be 
enclosed  in  parentheses 


e.g.  DISPLAI®  (KEYBOBDS,  SUFFIXES) 


Value  Stateuents 

Value  words  are  punched  in  free  foraat  in  coluans  1*71. 
Coluan  72  is  ignored.  Coluans  73*80  aay  optionally  contain 
a record  sequence  nuaber.  A word  aay  not  be  split  between 
two  records.  A suffix  specification  (explained  below)  aay 
not  be  split  between  two  records.  A suffix  specification 
need  not  appear  in  the  saae  record  as  its  root  word.  The 
parentheses  which  deliait  suffix  specifications  and  add- 
synonyas  aay  appear  anywhere  including  separate  cards.  Any 
nunber  of  blanks  or  conaas  aay  separace  words,  parentheses, 
and  suffix  specifications.  All  characters  except  the  blank, 
coaaa,  parenthesis,  and  equals  syabol  are  considered  to  be 
part  of  a word.  Words  are  stored  in  a table  exactly  as  they 
appear  in  the  input. 

( 

Stop  Word  Table  Entries 

siaple  words  are  stored  in  stop  word  tables.  Suffix  and 
synonym  notation  does  not  apply. 

Dictionary  Entries 

All  words  are  stored  in  the  dictionary  exactly  as  they 
appear  ia  the  input.  In  addition,  a changed  forn  of  the 
input  word  will  be  stored  if  a suffix  specification  follows 
the  input  word.  Both  forns  of  a word  aay  be  flagged  as 
synonyas  but  their  fora  is  not  changed. 

Suffix  Specification 

This  notation  is  used  with  words  whose  endings  change 
when  they  are  suffixed.  Three  such  words  are: 
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£22* 

ASH i -ABHIES  (changed  the  T to  I) . 

PLAN  -PLANNED  (add  an  N). 

ARGUE-ABGUHENT  (drop  the  B)  . 

The  specification  consists  of  a 1-byte  delete  count 
(always  a nuaber)  and  zero  or  nore  characters  that  are  to  be 
added  after  deletion  occurs.  The  specification  (one  or  nore 
separated  by  blanks  or  coanas)  aust  follow  its  root  word  and 
be  enclosed  in  parentheses. 

ARHY  (II)  delete  1(f),  add  I ~ ARBI 

PLAN  (ON)  delete  none,  add  N — PLANN 

ARGUE  (1)  delete  1(E),  add  none  — ARGO 

when  a changed  fora  dictionary  word  (ARBI,  PLANN,  ABGU) 
aatches  the  significant  characters  of  an  arguaent  word  and 
when  the  reaaining  arguaent  characters  are  a valid  suffix, 
the  root  word  (ARHY,  PLAN,  ARGUE)  is  substituted  for  the 
arguaent. 

Synonyas 

Synonoaous  relationships  between  words  are  defined  by 
enclosing  the  related  words  in  parentheses  in  an  add-synonya 
function  stateaent.  Any  nuaber  of  words  (two  or  aore)  aay 
appear  in  one  group.  The  saae  word  aay  appear  in  any  nuaber 
of  groups,  which  has  the  effect  of  coabiniag  the  words  in 
the  coaaon  groups  into  a single  group  internally.  OTNDXKHD 
collects  all  related  words  and  selects  the  lowest  in 
sequence  to  represent  the  group  in  the  Index  Data  Set.  This 
word  is  called  the  base  word;  all  other  words  are  called 
convert  words.  Bhen  as  arguaent  word  Batches  any  convert 
word,  the  base  word  is  substituted  for  the  arguaent. 

If  any  of  the  words  in  an  input  group  of  synonyas  is 
already  a synonoa  in  an  existing  table,  the  base  word  for 
the  existing  group  will  be  used  for  the  new  group;  i.e.,  all 
input  words  which  are  not  synonyas  will  be  stored  in  the 
dictionary  as  convert  words  in  the  existing  group. 
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15.2  UTNDXKHD  Output 

For  each  file  processed,  OTNDXKHD  lists  all  input 
stateaents  with  notes  to  indicate  the  action  taken  for  the 
stateaents. 

For  each  DISPLiY  function,  OTNDXKHD  lists  the  contents 
of  the  table  or  dictionary  ia  ascending  alphanuaeric 
sequence.  It  flags  all  convert  words  and  suffixed  words. 
It  also  shows  all  convert  words  as  sublists  with  each  base 
word  so  the  user  can  see  synonya  groups. 


15.3  OTNDXKHD  Job  Setup 

The  following  JCL  cards  are  used  to  invoke  the  cataloged 
procedure  XKN  which  will  aaintain  stop  word  tables  and 
diet ionaries. 

//jobnaae  JOB  (standard  paraaeters) 

//stepnaae  EXEC  XKH, LIB*libnaae 
//XKH.SYSIN  DD  * 

(user-supplied  control  stateaents) 

/* 

where 

libnaae  is  the  naae  of  the  library  containing  stop  word 
tables  and  dictionaries  to  be  aaintained. 


81 


Utility  Support  (DT) 


Section  16 

FOB HAT  DEFINITION  TRANSLATOR  OTILITI  (OTODE) 


UTODE  is  used  to  place  foraat  definitions  on  a user 
library.  A foraat  definition  gives  a description  of  a CUT 
display  foraat  and  the  Input  Message  Queue  records  to  be 
created  froa  data  entered  on  the  display.  Before  a user  can 
call  for  the  display  foraat  at  a CBT  terainal,  the  foraat 
definition  aust  reside  on  the  user  library.  0TODE  creates 
skeleton  and  IRQ  table  control  blocks  froa  the  foraat 
definition  source  stateaents  and  writes  the  control  blocks 
into  the  user  library  using  the  display  foraat  naae  as  the 
aeaber  naae. 


16.1  Input 

Input  to  UTODE  consists  of  one  or  aore  foraat 
definitions.  The  foraat  definition  source  stateaents  are 
described  in  Section  6 (FORHATTEB)  of  the  Terainal 
Processing  Users  Manual.  The  input  source  stateaents  aay  be 
in  punched  cards  or  in  card  iaage  records  stored  in  a 
partitioned  data  set. 


16.2  Job  Setup 

The  following  JCL  stateaents  illustrate  the  deck  setup 
used  to  execute  UTODE.  In  the  first  setup,  the  input 
definition  source  stateaents  are  in  punched  cards. 

//AA  EXEC  XUTOD£,LIB=TEST360,TLI B*# SER*HT PACK* 

//SISIH  DD  ♦ 

Definition  source  statenent  cards. 

/* 

The  following  JCL  would  be  used  if  the  input  were  card 
iaage  records  stored  in  a library. 


utility  Support  (UT) 


//AB  EXEC  XUT0DE,LIB*TEST3  BOOTHS*'  SER^HYPACK* 

//STSIM  OD  DSN*HY LIB (FORM ATI) #¥OL*S ER*BYPACK2 , 

//  DISP= (SHE, KEEP) #UHIT*231«, 

//  DCB* (HECFB«FB#LRECL*80#BLKSIXB«800) 

/* 
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